Проектирование реализации операций бизнес-процесса «Управление персоналом» (Создание контекстной диаграммы)

Содержание:

Введение

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

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

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

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

1. Анализ бизнес-процессов предприятия

1.1 Создание контекстной диаграммы

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

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

Действие (Activity) называемое функцией обрабатывает или переводит входные параметры в выходные. Функция, описывающая систему в целом, называется контекстной функцией. Функции обозначаются в виде поименованных прямоугольников. Все функции (действия или работы) должны быть названы и определены [2]

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

Рисунок 1. Функциональный блок

Взаимодействие с окружающим миром описывается в следующих терминах:

• входы (данные или объекты, потребляемые или изменяемые процессом);
• выходы (основной результат деятельности процесса, конечный продукт);
• управление (стратегии и процедуры, которыми руководствуется процесс);
• механизмы (ресурсы, необходимые для процесса).

Основную задачу предприятия демонстрирует контекстная диаграмма.

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

1.2 Диаграммы декомпозиции

Любой блок может быть декомпозирован на составляющие блоки. Функциональную декомпозицию можно определить как моделирование “снаружи вовнутрь”

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

Рисунок 3. Диаграмма декомпозиции 1 уровня

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

Рисунок 4. Декомпозиция второго уровня работы “Работа с фирмами работодателями”

Рисунок 5. Декомпозиция второго уровня работы «Работа с соискателями»

2. Проектирование ИС

2.1 Подходы к проектированию ИС

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

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

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

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

Во второй половине 80х годов появилось методология объектно-ориентированного программирования

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

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

«Объектно-ориентированные системы более открыты и легче поддаются внесению изменений , поскольку их конструкция базируется на устойчивых формах. Это дает возможность системе развиваться постепенно и не приводит к полной ее переработке даже в случае существенных изменений исходных требований». [3]

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

2.2 Унифицированный язык моделирования UML

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

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

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

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

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

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

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

Потребность в качестве процесса разработки обуславливает необходимость создания стандартных условных обозначений. Язык UML представляет собой именно такую систему обозначений.

Авторами UML являются Гради Буч (Grady Booch), Джеймс Румбах (James Rumbaugh) и Айвар Якобсон (Ivar Jacobson). Известные как «три товарища», в 80-х – начале 90-х годов они работали в разных организациях и независимо друг от друга продумывали методологии объектно-ориентированного анализа и проектирования, которые имели явные преимущества перед всеми остальными известными методами. В середине 90-х годов они стали заимствовать идеи друг у друга и поэтому решили объединить свои усилия.

В 1994 году Румбаха пригласили в компанию Rational Software Corporation, где в это же время уже работал Буч. Через год к ним присоединился Якобсон.

Предварительные версии UML начали использоваться в области создания программного обеспечения, а на основании отзывов потребителей производились существенные доработки. Многие корпорации ощутили, что язык UML может оказаться полезен для достижения их стратегических целей. Это привело к возникновению консорциума UML, в который вошли такие компании, как DEC, Hewlett-Packard, Intellicorp, Microsoft, Oracle, Texas Instruments, Rational и другие. В 1997 году консорциум выработал первую версию UML и представил ее на рассмотрение группе OMG (Object Management Group), откликнувшись на ее запрос о подаче предложений по стандартному языку моделирования.[6]

После расширения консорциума вышла версия 1.1 языка UML, которую группа OMG приняла в конце 1997 года. После этого OMG приступила к сопровождению UML и выпустила в 1998 году две его новые версии. Язык UML стал стандартом де-факто в области разработки программного обеспечения. В настоящее время этот язык продолжает активно развиваться

Язык UML предназначен для решения следующих задач:

1. Предоставить пользователю легко воспринимаемый язык визуального моделирования, специально предназначенный для разработки и документирования моделей сложных систем самого различного целевого назначения.
2. Снабдить исходные понятия языка UML возможностью расширения и специализации для более точного представления моделей системы в ООАП (объектно-ориентированный анализ и проектирование)конкретной предметной области.
3. Ни одна из конструкций языка UML не должна зависеть от особенностей ее реализации в известных языках программирования.
4. Поощрять развитие рынка объектных инструментальных средств.
5. Способность совершенствоваться.
6. Интегрировать в себя новейшие и наилучшие достижения практики

В рамках языка 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 диаграмм

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

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

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

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

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

Таблица 1

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

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

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

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

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

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

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

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

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

Диаграммы поведения

2.4 Диаграммы состояний

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

Таблица 2

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

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

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

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

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

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

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

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

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

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

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

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

• • 1. Диаграмма деятельности

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

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

Таблица 3

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

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

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

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

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

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

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

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

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

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

2.5 Диаграммы взаимодействия

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

В работе было выполнено проектирование и разработка информационной системы для управления персоналом. Реализация ее позволяет повысить качество обслуживания клиентов, упростить поиск вакансий и соискателей.

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

На начальных этапах создания ИС необходимо понять, как работает организация, которую собираемся автоматизировать. Для описания работы необходимо построить модель адекватную предметной области. Для описания бизнес процессов предприятия использовалась методология структурного анализа и проектирования IDEF0 . Построение моделей осуществлялось при помощи CASE средства BPWin.

Структурный анализ использовался в качестве основы для объектно - ориентированного проектирования.

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

При проектировании ИС был использован унифицированный язык моделирования UML и CASE средство Rational Rose . На основе полученных диаграмм в дальнейшем разрабатывался интерфейс пользователя.

Список использованной литературы

1. Вендров А.М. Проектирование программного обеспечения экономических информационных систем. - М.: Финансы и статистика, 2010
2. Д.Розенберг, К.Скотт. Применение объектного моделирования с использованием UML и анализ прецедентов.— Москва: ДМК-издательство, 2009.
3. Лешек А. Мацяшек. Анализ требований и проектирование систем. Разработка информационных систем с использованием UML. — Москва-Санкт-Петербург-Киев: Вильямс, 2010. – 202с.
4. Маклаков С.В. CASE-средства разработки информационных систем. – М.:ДИАЛОГ МИФИ, 2009. – 304 с.
5. Мартин Фаулер и Кендалл Скотт, UML. Основы.- СПб: Символ-Плюс, 2012
6. Михеева В. Д., Харитонова И. А., Microsoft Access 2007.- СПб: БХВ–Петербург, 2008
7. Смирнов Г.Н., Сорокин А.А, Тельнов Ю.Ф. Проектирование экономических информационных систем. – М.: Финансы и статистика, 2011 – 512 с.
8. Терри Кватрани. Rational Rose 2000 и UML. Визуальное моделирование. — Москва: ДМК-издательство, 2009.
9. Черемных С.В., Семенов И.О., Ручкин В.С. Структурный анализ систем: IDEF-технология. - М.: Финансы и статистика, 2011. - 208 с.