Преподаватель который помогает студентам и школьникам в учёбе.

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

Содержание:

Введение

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

Наиболее удобным способом хранения информации является создание базы данных на основе уже имеющейся информации.

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

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

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

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

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

Методология проектирования информационных систем

Унифицированный язык моделирования 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 предназначен для решения следующих задач:

Предоставить пользователю легко воспринимаемый язык визуального моделирования, специально предназначенный для разработки и документирования моделей сложных систем самого различного целевого назначения.
Снабдить исходные понятия языка UML возможностью расширения и специализации для более точного представления моделей системы в ООАП (объектно-ориентированный анализ и проектирование)конкретной предметной области.
Ни одна из конструкций языка 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 и предназначенные для моделирования ПО, позволяют еще на этапе разработки проверить архитектурные решения, полноту модели, ее корректность, для того, чтобы, в том числе, уменьшить риск «провала» проекта. Опишем некоторые из графических диаграмм, построенных при разработке нашей системы.

Описание UML диаграмм в Rational Rose

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

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

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

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

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

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

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

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

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

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

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

Таблица 1

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

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

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

Таблица 2

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

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

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

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

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

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

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

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

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

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

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

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

Таблица 3

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

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

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

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

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

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

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

моделирование предметной области с использованием модели UML

Постановка задачи проектирования

Основными требованиями к базе данных являются [2]:

1. Минимальная избыточность. Данные, хранимые в БД, могут содержать как "полезную", так и "вредную" избыточность. Последняя всегда имеет место при отсутствии концептуального представления данных, когда каждый пользователь создает для своих приложений отдельный набор данных. В этом случае, если нескольким пользователям требуются одни и те же данные, то они должны быть повторены в каждом наборе. Такая избыточность является неконтролируемой, поскольку о ее существовании пользователи могут и не подозревать. Интеграция пользовательских представлений в единое концептуальное представление, как правило, устраняет эту избыточность данных. К "полезной" избыточности можно отнести периодические копии данных, хранящихся в БД. Эта избыточность легко контролируется. Более того, она является необходимой, например, для восстановления данных, разрушенных при случайных сбоях и в катастрофических ситуациях.

Таким образом, требование минимальной избыточности следует понимать как устранение "вредной" (неконтролируемой) и сведение к минимуму "полезной" (контролируемой) избыточности данных;

2. Целостность данных:

а) актуальность

б) правильность данных

3. Безопасность и секретность данных

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

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

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

5. Высокая производительность данных. Характеризуется временем ответа на запросы пользователей.

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

Построение диаграмм

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

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

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

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

ГОСТ 34.601-90. Автоматизированные системы. Стадии создания.
ГОСТ 34.602-89. Информационная технология.
Автоматизированные информационные технологии в экономике /Под ред. проф. ГА, Титоренко. - М.: ЮНИТИ, 2008.
Введение в системы баз данных – СПб: Издательский дом «Вильямс», 2010. - 848с.
Вендров А.М. Проектирование программного обеспечения экономических информационных систем. - М: Финансы и статистика, 2010
Грекул В.И., Денищенко Г.Н., Коровкина Н.Л. Проектирование информационных систем – М.: ИНТУИТ.ру, 2005
Д.Розенберг, К.Скотт. Применение объектного моделирования с использованием UML и анализ прецедентов.— Москва: ДМК-издательство, 2002.
Данелян Т.Я. Организация и функционирование больших информационных систем. – М.: МЭСИ, 2007
Информационные системы в экономике /Под ред. В.В. Дика. - М.: Финансы и статистика, 2006.
Крис Дейт. Введение в базы данных, 6-е изд. Киев, Диалектика, 1998.
Лешек А. Мацяшек. Анализ требований и проектирование систем. Разработка информационных систем с использованием UML. — Москва-Санкт-Петербург-Киев: Вильямс, 2002.
Маклаков С.В. CASE-средства разработки информационных систем. – М.:ДИАЛОГ МИФИ, 2001. – 304 с.
Мартин Фаулер и Кендалл Скотт, UML. Основы.- СПб: Символ-Плюс, 2002
Разработка программного обеспечения - СПб: Питер, 2004. - 592с.
Реляционные базы данных: практические приемы оптимальных решений. – СПб.: БХВ-Петербург, 2005. – 400с.
Смирнов Г.Н., Сорокин А.А, Тельнов Ю.Ф. Проектирование экономических информационных систем. – М.: Финансы и статистика, 2001 – 512 с.
Терри Кватрани. Rational Rose 2000 и UML. Визуальное моделирование. — Москва: ДМК-издательство, 2001.
Черемных С.В., Семенов И.О., Ручкин В.С. Структурный анализ систем: IDEF-технология. М.: Финансы и статистика, 2001, 208 с.