Объектно-ориентированный анализ и проектирование с использованием UML и IBM Rational Rose

Нотация и семантика языка UML

2-е издание, исправленное

Леоненков А.В.

Национальный Открытый Университет “ИНТУИТ”
2016

2

УДК 004.438(075.8)
ББК 45
Л47
Объектно-ориентированный анализ и проектирование с использованием UML и IBM Rational Rose /
Леоненков А.В. - M.: Национальный Открытый Университет “ИНТУИТ”, 2016 (Основы
информационных технологий)
ISBN 5-94774-408-2

Предметом курса является описание нотации языка UML версии 1.5 и особенностей процесса
объектно-ориентированного анализа, проектирования и разработки программных приложений.
Представлены определения базовых конструкций языка UML и нотация графических элементов,
используемых при построении моделей программных систем и бизнес-процессов. Последовательно
рассматриваются все типы канонических диаграмм языка UML и практические рекомендации по их
построению. Применение рассматриваемых конструкций языка UML иллюстрируется практическими
примерами диаграмм моделей.
Курс ориентирован на начинающих и более опытных руководителей и менеджеров проектов
разработки программных и информационных систем, системных аналитиков, корпоративных
программистов, разработчиков баз данных и интерфейсов к базам данных, бизнес-аналитиков и
руководителей информационных служб, CIO и MIS, ставящих перед собою цели получения или
повышения квалификации в области современных технологий разработки программных проектов и
моделей бизнес-систем. Для иллюстрации материала используются диаграммы визуального
моделирования, паттерны проектирования и анализа, а также фрагменты реализации отдельных
проектов разработки программных систем. Для спецификации и визуализации различных
представлений моделей используются канонические диаграммы языка UML. Курс посвящен
изучению основ нотации Унифицированного языка моделирования или, сокращенно, языка UML,
который предназначен для описания, визуализации и документирования объектно-ориентированных
систем и бизнес-процессов с ориентацией на их последующую реализацию в виде программного
обеспечения. Изучение материала курса направлено на формирование и совершенствование знаний
по методологии описания, визуализации и документирования объектно-ориентированных систем и
бизнес-процессов с помощью языка UML. Полученные в ходе изучения курса знания могут быть
успешно использованы в последующем при совершенствовании бизнес-процессов и управлении
проектами в ходе разработки информационных моделей и программных приложений. Знание
изучаемых в курсе базовых конструкций языка UML позволит слушателям самостоятельно
использовать CASE-средства с целью автоматизации выполнения всех этапов концептуального,
логического и физического проектирования архитектуры корпоративных информационных систем и
программных приложений. В основу курса положены две основные идеи. С одной стороны,
рассмотреть все базовые конструкции языка UML, необходимые для разработки концептуальных,
логических и физических моделей программных систем и бизнес-процессов. С другой стороны,
донести до читателя основы методологии визуального моделирования сложных систем, без
понимания которой вряд ли возможно адекватно и безошибочно использовать потенциал
возможностей языка UML. Курс лекций последовательно знакомит читателей с нотацией и
назначением всех канонических диаграмм языка UML: вариантов использования, классов,
кооперации, последовательности, состояний, деятельности, компонентов, и развертывания. Для
каждой из диаграмм описываются базовые элементы графической нотации, необходимые для
изображения различных элементов моделей, приводятся рекомендации по разработке отдельных
диаграмм и практические примеры.

(c) ООО “ИНТУИТ.РУ”, 2006-2016
(c) Леоненков А.В., 2006-2016

3

Современные технологии объектно-ориентированного анализа и
проектирования информационных систем

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

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

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

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

Модель (model) - абстракция физической системы, рассматриваемая с определенной
точки зрения и представленная на некотором языке или в графической форме.

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

4

привели к появлению языка UML.

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

Методология объектно-ориентированного программирования

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

Объектно-ориентированное программирование (ООП, Object-Oriented Programming) совокупность принципов, технологий, а также инструментальных средств для создания
программных систем на основе архитектуры взаимодействия объектов.

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

Основные принципы ООП: абстракция, наследование, инкапсуляция и полиморфизм.

Абстракция (abstraction) - характеристика сущности, которая отличает ее от других
сущностей. Абстракция определяет границу представления соответствующего
элемента модели и применяется для определения фундаментальных понятий ООП,
таких как класс и объект.

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

Объекты, которые не имеют идентичных свойств или не обладают одинаковым
поведением, по определению, не могут быть отнесены к одному классу.

5

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

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

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

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

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

6

Рис. 1.1.  Иерархия вложенности классов для примера общего класса “Компьютер”

Подобное изображение обладает серьезным недостатком. Из представленного рисунка
не ясно, изображена ли на нем иерархия понятий или декомпозиция класса
“Компьютер” на его составные части. Как будет показано далее, использование
нотации UML позволяет устранить данную неопределенность посредством введения в
рассмотрение двух различных отношений: обобщения и агрегации (Лекция 6).

Следующий принцип ООП - инкапсуляция. Инкапсуляция характеризует сокрытие
отдельных деталей внутреннего устройства классов от внешних по отношению к нему
объектов или пользователей.

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

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

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

7

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

Полиморфизм также один из основных принципов ООП. Под полиморфизмом (греч.
Poly - много, morfos - форма) понимается свойство объектов принимать различные
внешние формы в зависимости от обстоятельств. Применительно к ООП полиморфизм
означает, что действия, выполняемые одноименными методами, могут различаться в
зависимости от того, к какому из классов относится тот или иной метод.

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

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

Наиболее существенным обстоятельством в развитии методологии ООП явилось
осознание того, что процесс написания программного кода может быть отделен от
процесса проектирования структуры программы. Прежде, чем начать
программирование классов, их свойств и методов, необходимо определить сами эти
классы. Более того, нужно дать ответы на следующие вопросы: сколько и какие классы
нужно определить для решения поставленной задачи, какие свойства и методы
необходимы для придания классам требуемого поведения, а также установить
взаимосвязи между классами. Эта совокупность задач не столько связана с написанием
кода, сколько с общим анализом требований к будущей программе, а также с анализом
конкретной предметной области, для которой разрабатывается программа. Все эти
обстоятельства привели к появлению специальной методологии, получившей название
методологии объектно-ориентированного анализа и проектирования (ООАП).

Методология объектно-ориентированного анализа и
проектирования

Необходимость анализа предметной области до начала написания программы была

8

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

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

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

Объектно-ориентированный анализ и проектирование (ООАП, Object-Oriented
Analysis/Design) - технология разработки программных систем, в основу которых
положена объектно-ориентированная методология представления предметной области
в виде объектов, являющихся экземплярами соответствующих классов .

Методология ООАП тесно связана с концепцией автоматизированной разработки
программного обеспечения (Computer Aided Software Engineering, CASE). К первым
CASE-средствам отнеслись с определенной настороженностью. Со временем
появились как восторженные отзывы об их применении, так и критические оценки их
возможностей. Причин для столь противоречивых мнений было несколько. Первая из
них заключается в том, что ранние CASE-средства были простой надстройкой над
системой управления базами данных (СУБД). Визуализация процесса разработки
концептуальной схемы БД имеет немаловажное значение, тем не менее, она не решает
проблем создания приложений других типов.

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

9

В рамках ООАП исторически рассматривались три графических нотации:

диаграммы “сущность-связь” (Entity-Relationship Diagrams, ERD),
диаграммы функционального моделирования (Structured Analysis and Design
Technique, SADT),
диаграммы потоков данных (Data Flow Diagrams, DFD).

Диаграммы “сущность-связь” (ERD) предназначены для графического представления
моделей данных разрабатываемой программной системы и предлагают набор
стандартных обозначений для определения данных и отношений между ними. С
помощью этого вида диаграмм можно описать отдельные компоненты концептуальной
модели данных и совокупность взаимосвязей между ними.

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

Связь (relationship) определяется как отношение или ассоциация между отдельными
сущностями. Примерами связей могут являться родственные отношения, в частности
“отец-сын” или производственные - “начальник-подчиненный”. Другой тип связей
задается отношениями “иметь в собственности” или “обладать свойством”. Различные
типы связей графически изображаются в форме ромба с соответствующим именем
данной связи.

Графическая модель данных строится таким образом, чтобы связи между отдельными
сущностями отражали не только семантический характер соответствующего
отношения, но и дополнительные аспекты обязательности связей, а также кратность
участвующих в данных отношениях экземпляров сущностей. Нотация диаграмм (ERD)
реализована в различных программных средствах. Пример диаграммы ERD,
разработанной с помощью средства моделирования бизнес-процессов ARIS 
изображен на рис.1.2.

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

10