Тема 3. Визуальное
моделирование при анализе и проектирование.
Основы Unified
modeling language (UML)
1.
Вспоминая предыдущую лекцию
4.
Структура языка UML.
Модели UML. Диаграммы UML. Понятия UML
5.
Учебный пример: Система бронирования билетов для авиакомпании
6.
Визуальное описание функциональной модели средствами UML. Актеры и варианты
использования в UML
8.
Литература
1.
Вспоминая предыдущую лекцию
Программная инженерия, основные понятия
-
Инженеры и
программные инженеры: Инженер -
дипломированный специалист, имеющий высшее техническое образование. Программный
инженер – инженер в области разработки программного обеспечения
-
Программная
инженерия как
инженерная дисциплина – связана с теорией, методами и средствами
профессиональной разработки ПО
-
Область
действия программной инженерии
- Поиск
финансирования.
- Работа с
заказчиком.
- Подбор
персонала.
- Этические
вопросы. Микроклимат в коллективе. Команда.
- Обеспечение
качества программного продукта.
-
Цели
программных инженеров
- Создать
качественный продукт.
- Уложиться в
бюджет.
- Уложиться в
сроки.
-
Программные
инженеры и научная среда
- Новые
технологии.
- Новые методы,
алгоритмы.
- Анализ новых
перспективных разработок.
- Исследовательская
работа в смежных областях.
Помощь ученых жизненно необходима в по крайней
мере в двух ситуациях:
- Там, где в
принципе не решить задачу своими силами.
- Там, где есть
специалисты, но нет времени и ресурсов для исследований.
Этот подход широко применяется современными IT-компаниями: Intel, Microsoft, IBM и
другими.
Процесс
создания ПО
-
Понятие
процесса. Основные фазы.
-
Модель
процесса. Каскадная и эволюционная модель.
-
Итерационный
подход. Модель пошаговой разработки и спиральная модель.
1.
Анализ и проектирование. Некоторые
частные вопросы
В прослушанных
ранее программистских дисциплинах неоднократно рассматривалась типовая схема
решения задач с использованием вычислительной техники. При этом особое внимание
уделялось тому, что непосредственное программирование или написание кода
начинается далеко не сразу. Более того, этапы, предшествующие разработки не
менее важны и сложны. Примерная схема, отражающая процесс от постановки задачи
до выпуска готового продукта может выглядеть так:
Или в
укрупненном виде:
3-я часть и
элементы 2-ой части этой цепочки изучаются в курсе «Методы программирования».
1-я и 2-я
части составляют объект изучения отдельного курса «Анализ и проектирование».
В настоящий
момент в анализе и проектировании преобладает объектный подход (изучен в 1-2
семестрах).
Вспомним суть
объектного подхода.
1.1. Обзор принципов объектного подхода
1.1.1.
Алгоритмическая и объектная
декомпозиции. Классы и объекты
Принципиально
можно выделить 2 вида разбиения предметной области на составляющие элементы:
–
Алгоритмическая декомпозиция (основные
элементы программы – строительные блоки – алгоритмы).
–
Объектная декомпозиция (основные элементы программы – виды
абстракций (классы) и представители этих классов
(объекты)).
В соответствии
с алгоритмической декомпозицией предметной области мы при анализе задачи
пытаемся понять, какие алгоритмы необходимо разработать для ее решения, каковы
спецификации этих алгоритмов (вход, выход), и как эти алгоритмы связаны друг с
другом. В языках программирования данный подход в полной мере поддерживается
средствами модульного программирования (библиотеки, модули, подпрограммы).
В рамках
объектной декомпозиции мы пытаемся выделить основные содержательные элементы
задачи, разбить их на типы (классы). Далее для каждого класса абстракций мы
определяем его свойства (данные) и поведение (операции), а также, как эти
классы абстракций взаимодействуют друг с другом.
На сегодняшний
день объектный подход и его основы – объектная модель и объектная декомпозиция
– поддерживаются современными объектно-ориентированными языками
программирования (Object Pascal, C++, Java, C#…).
1.1.2.
Составные части объектного подхода
Как было
сказано ранее, основами объектного подхода являются объектная модель и объектная
декомпозиция. Рассмотрим кратко составные части объектного подхода, грамотное
выполнение которых, как правило, приводит к созданию качественного программного
продукта.
Объектный
подход:
-
OOA (object oriented analysis) – объектно-ориентированный
анализ.
-
OOD (object
oriented design)
– объектно-ориентированное
проектирование.
-
OOP (object
oriented programming)
– объектно-ориентированное
программирование.
Рассмотрим кратко эти ключевые понятия (определения Г. Буча):
Объектно-ориентированный
анализ
— это методология, при которой требования к системе воспринимаются с точки
зрения классов и объектов, выявленных в предметной области [2].
Объектно-ориентированное
проектирование
— это методология проектирования, соединяющая в себе процесс объектной декомпозиции
и приемы представления логической и физической, а также статической и
динамической моделей проектируемой системы [2].
Объектно-ориентированное
программирование
— это методология программирования, основанная на представлении программы в
виде совокупности объектов, каждый из которых является экземпляром
определенного класса, а классы образуют иерархию наследования [2].
В
русскоязычной литературе, как правило, под аббревиатурой ООП рассматривают все
3 составляющих объектного подхода. Далее и мы будем следовать этому принципу.
Курсы из цикла
«Методы программирования» и, конкретнее, «Объектно-ориентированное
программирование» преимущественно концентрируются на OOP.
Данный курс, по крайней мере, его теоретическая часть основное внимание уделяет
OOA и OOD.
1.1.3.
Принципы объектного подхода
Рассмотрим
наиболее важные принципы объектного подхода.
Абстрагирование применяется
при решении многих задач. Любая построенная нами модель позволяет
абстрагироваться от реального объекта, подменяя его изучение исследованием формальной
модели. Абстрагирование в ООП позволяет выделить основные элементы предметной
области, обладающие одинаковой структурой и поведением. Такое разбиение на
классы позволяет существенно облегчить анализ и проектирование системы.
Инкапсуляция – важнейший
элемент объектного подхода. Суть его заключается в скрытии деталей внутренней
реализации. Инкапсуляция оказывает положительное влияние на защиту данных и
существенно повышает шансы безболезненной замены одной из частей системы ее
новой версией при условии сохранения интерфейса.
Иерархия помогает разбить задачу на уровни и
постепенно ее решать, постепенно увеличивая детализацию рассмотрения. Иерархия
упорядочивает абстракции. К счастью, разные иерархии можно обнаружить
практически в любой системе. Агрегация и наследование
– примеры таких иерархий. Они подчеркивают тот факт, что новые абстракции могут
быть созданы на основе уже имеющихся.
Полиморфизм позволяет иметь естественные имена и
выполнять действия, релевантные ситуации, разбираясь на этапе работы программы,
какой из методов необходимо вызвать. Полиморфизм неразрывно связан с
наследованием и поздним связыванием.
1.1.4.
Пример: ООП и структуры хранения.
Стек
Постановка
задачи:
Необходимо
разработать структуру хранения Стек.
Примечания:
-
Не
учитывать необходимость перераспределения памяти.
-
Считать,
что элементы целого типа.
Анализ и
проектирование.
Данные:
-
MemSize – максимальное количество элементов.
-
DataCount – количество
элементов в стеке.
-
pMem – указатель на
память для хранения значений.
Операции:
-
IsFull – проверка на полноту.
-
IsEmpty – проверка на пустоту.
-
Get – взять
элемент с вершины.
-
Put – положить
элемент в стек.
Рассмотрим
финальный результат нашего проектирования (используется нотация UML):
1.2. Повторное использование
1.2.1.
Идея повторного использования.
Важность повторного использования
Повторное
использование
– применение уже существующих наработок в разрабатываемом ПО.
Повторное
использование – важный элемент проектирования. Необходимо проектировать новые
элементы системы с тем, чтобы их в последствии можно было применять при
разработке других систем. Кроме того, при проектировании системы необходимо
рассматривать возможность использования того, что уже есть и работает.
Девиз:
не
надо изобретать велосипед, если он уже изобретен.
1.2.2.
Достоинства повторного
использования. Виды повторного использования
Достоинства
повторного использования (по Соммервилю, [1]):
-
Повышение
надежности.
-
Уменьшение
проектных рисков.
-
Эффективное
использование специалистов.
-
Соблюдение
стандартов (пример: пользовательский интерфейс).
-
Ускорение
разработки.
Повторное
использование достигается за счет следующих приемов (видов использования):
-
Компонентная разработка. Часть
компонентов уже разработаны ранее, имеют четко описанный интерфейс. Они
используются в качестве «кирпичиков» в новой системе.
Использование
паттернов (шаблонов) проектирования. Применяются известные подходы к
решению некоторых встречавшихся ранее проблем.
Использование
стандартных прикладных (MKL, MFC…) и системных (API) библиотек.
2.
Визуальное моделирование. История
языка UML
2.1. Идея визуального моделирования
Вспомним, в
чем состоит основная проблема в разработке ПО? Проекты не укладываются в сроки,
бюджет, не удовлетворяют требованиям.
Как решать эту
проблему? На помощь приходит моделирование.
Под моделью
обычно понимают упрощенное представление объектов и явлений реального мира.
Ответим на
вопрос, зачем строят модели? Модели строят
для того, чтобы лучше понять исследуемую систему.
Классики
проклассифицировали задачи и принципы моделирования. Приведем здесь эту,
несомненно, важную, классификацию.
Задачи
моделирования
[3]:
-
Визуализация
системы в ее некотором состоянии.
-
Определение
структуры и поведения системы.
-
Получение
шаблона для создания системы.
-
Документирование
принятых решений.
Принципы
моделирования
[3]:
-
Выбор
модели оказывает определяющее влияние на подход к решению проблемы и на то, как
будет выглядеть это решение.
-
Каждая
модель может быть воплощена с разной степенью абстракции.
-
Лучшие
модели – те, что ближе к реальности.
-
Наилучший
подход при разработке сложной системы – использовать несколько почти
независимых моделей.
Как уже
упоминалось ранее, одним из наиболее популярных подходов к моделированию
является объектный подход. В соответствии с этим подходом в результате OOA и OOD
мы
получаем «хороший» проект программной системы, прозрачный, удовлетворяющий
требованиям, удобный для тестирования и отладки, коллективной разработки,
развиваемый, допускающий повторное использование компонентов.
К сожалению,
даже использование таких мощных средств, как объектный подход, не гарантирует
нам успех. К сожалению, в больших проектах сложность моделируемого объекта (и,
соответственно, сложность проекта) такова, что проект слишком велик для
адекватного восприятия одним человеком, по крайней мере, в уме.
Это и означает
необходимость визуального моделирования.
Идея
визуального моделирования состоит в графическом отображении обсуждаемых и принимаемых проектных решений. При этом
достигаются следующие цели:
-
Визуализация упрощает понимание проекта в целом.
-
Визуализация помогает согласовать терминологию и
убедиться, что все одинаково понимают термины.
-
Визуализация делает обсуждение конструктивным и
понятным.
Для
визуального моделирования нужна специальная нотация или язык.
UML (unified modeling language) – это язык
для визуализации, специфицирования, конструирования, документирования
элементов программных систем [3]. UML – язык общего
назначения, предназначенный для объектного моделирования.
2.2. История языка UML
Рассмотрим
кратко историю языка UML. К 1994 году
существовало несколько нотаций для визуального отображения принимаемых
проектных решений и несколько методов анализа и проектирования. В 1994 году
состоялось знаковое событие – Grady Booch и James
Rumbaugh, сотрудники фирмы Rational Software,
объединили свои методы проектирования и анализа, создав так называемый Unified method. С этого
момента процесс стандартизации договоренностей вошел в рабочий ритм. Приведем
важные вехи этого пути:
-
1994: Grady Booch & James Rumbaugh (Rational
Software) объединили методы
Booch (проектирование) и OMT (анализ) ->Unified method.
-
1995: присоединился Ivar Jacobson (автор метода
OOSE). Впоследствии группа авторов Booch, Rumbaugh и Jacobson вместе выпустила
не одну книгу, ставшую бестселлером (например, см. список литературы). Эту
троицу шутливо называли «three amigos», намекая на то, как жарко они спорили по
поводу принимаемых решений.
- 1996 – Идея о Unified Modeling Language
(three amigos).
-
1996 – создан консорциум UML Partners под
руководством three amigos.
-
Июнь, Октябрь 1996 – UML 0.9 & UML 0.91.
-
Январь 1997 – спецификации UML 1.0 предложены OMG
(Object Management Group).
-
Август 1997 – спецификации UML 1.1 предложены OMG.
-
Ноябрь 1997 – UML 1.2 – результат адаптации OMG.
-
Июнь 1999 – UML 1.3.
-
Сентябрь 2001 – UML 1.4.
-
Март 2003 – UML 1.5.
Принятый стандарт:
- ISO/IEC 19501:2005
Information technology – Open Distributed Processing – Unified Modeling
Language (UML) Version 1.4.2.
-
Октябрь 2004 – UML 2.0.
3.
Структура языка UML
3.1. Модели UML
UML позволяет описывать систему следующими
моделями:
-
Модель функционирования (показывает, как
описывается функциональность системы с точки зрения пользователя).
-
Объектная модель (показывает, как выглядит проект системы с точки зрения
объектного подхода).
-
Динамическая модель (показывает, как
взаимодействуют друг с другом компоненты системы в динамике, с течением
времени). Демонстрирует, какие процессы происходят в системе.
3.2. Диаграммы UML
Диаграммы
UML предназначены
для визуального отображения моделей
и их компонентов.
UML 2.0 содержит 13
типов диаграмм. В том числе:
-
Структурные диаграммы (6).
-
Диаграммы поведения (3).
-
Диаграммы взаимодействия (4).
Рассмотрим каждую из групп подробнее:
Структурные
диаграммы:
-
Диаграмма классов – показывает
классы, их атрибуты и связи между классами.
-
Диаграмма компонентов – показывает
компоненты и связи между ними.
-
Структурная диаграмма – показывает
внутреннюю структуру классов и связи с внешним миром.
-
Диаграмма развертывания - показывает,
как ПО размещается на аппаратуре (серверах, рабочих станциях...).
-
Диаграмма объектов – показывает
структуру системы в конкретный момент времени, объекты, их атрибуты...
-
Диаграмма пакетов – показывает,
как система раскладывается на крупные составные части и связи между этими
частями
Диаграммы
поведения:
-
Диаграмма действия – показывает
потоки информации в системе.
-
Диаграмма состояния – представляет
собой конечный автомат, показывающий функционирование системы.
-
Диаграмма вариантов использования – показывает
работу системы с точки зрения пользователей.
Диаграммы
взаимодействия
-
Диаграмма кооперации – показывает
структурную организацию участвующих во взаимодействии объектов.
-
Диаграмма взаимодействия (новация UML 2.0).
-
Диаграмма последовательности – показывает
временную упорядоченность событий.
-
Временная диаграмма –
диаграмма связана с временными
рамками проекта.
3.3. Понятия UML
Для описания
структуры:
Актер, Атрибут, Класс, Компонент, Интерфейс, Объект, Пакет.
Для описания поведения: Действие,
Событие, Сообщение, Метод, Операция, Состояние, Вариант использования.
Для описания связей: Агрегация,
Ассоциация, Композиция, Зависимость, Наследование.
Некоторые другие понятия: Стереотип,
Множественность, Роль.
4.
Учебный пример: Система
бронирования билетов для авиакомпании
4.1. Краткое описание
На рынок вышла
новая авиакомпания «GlobalAvia». Менеджеры
компании решили заказать у вашей фирмы разработку системы бронирования билетов.
При заказе фирма поставила ряд условий, которые обязательно должны быть
выполнены. В первой версии системы они хотят видеть две части. Работа первой
части системы связана с занесением информации. Вторая часть системы
предназначена для общения с клиентами.
При формулировании
требований менеджеры упомянули, что рейсы спланированы так, что до пункта
назначения можно долететь с пересадками. Одно из требований заключалось в том,
чтобы система помогала покупать билеты в зависимости от пожеланий пользователя.
4.2. Анализ постановки – полное описание
-
Задача является математической. Система должна уметь
решать однокритериальную задачу поиска кратчайших путей на графах. Критерий –
цена.
-
Система распределенная: так как в каждом аэропорте
своя база направлений полетов самолетов, то знают о рейсе только
аэропорты-соседи по рейсам.
Объекты
системы:
распределенное хранилище рейсов, покупатель билетов, менеджер рейсов.
-
Распределенное хранилище рейсов: название рейсов, номера и стоимость билетов.
-
Покупатель: ФИО,
сумма. Покупатель задает параметры, связанные с суммой, которую он хочет
потратить. Система должна подобрать оптимальный маршрут. При отсутствии прямых
маршрутов система должна попробовать найти маршруты с пересадками. Если таковых
не находится, система должна сказать, что с такими ограничениями нельзя
добраться до места назначения.
Среди причин:
-
Отсутствие рейсов в желаемом направлении даже с
учетом пересадок.
-
Нехватка денег.
В ответ,
пользователь должен иметь возможность поменять параметры с учетом предыстории.
-
Менеджер
рейсов:
должен иметь следующие возможности:
·
создания
и удаления аэропортов в системе.
·
создания
и удаления рейсов в аэропортах.
5.
Визуальное описание функциональной
модели средствами UML
5.1. Актеры и варианты использования в UML
Программная
система не функционирует сама по себе. Программная система функционирует под
воздействием актеров (Actor) – пользователей, машин и других
программ. При этом актер ожидает, что система ведет себя строго определенным
образом. Актер оказывает воздействие – система выдает ожидаемый результат. В
случае, если ожидаемого результата нет, требования пользователя не
удовлетворены со всеми вытекающими отсюда результатами. Таким образом, актер
в UML – человек, машина или программа,
воздействует на систему, является внешним по отношению к ней. Модель того, как
воздействие приводит к результату, называется Вариантом
использования (Use case). Актеры
и варианты использования имеют специальные обозначения в UML:
Актеры и
варианты использования общаются посредством посылки сообщений. Сообщения могут
идти в обе стороны. Стрелка показывает инициатора общения (актер на рисунке) и
может быть опущена.
Выделим
актеров и варианты использования в рассмотренном ранее примере с системой
бронирования билетов (SRS). Анализ
постановки задачи показывает наличие у системы двух актеров: «Пользователь» и
«Администратор». Определимся с вариантами использования. Необходимо отметить,
что выбор актеров и вариантов использования до некоторой степени условен и
может отличаться у разных специалистов по анализу и проектированию. Принятые
проектные решения определяют дальнейший выбор архитектуры системы и существенно
влияют на успех всего процесса разработки. При этом «хороших» вариантов может
быть несколько.
Перечень
Вариантов использования для нашей задачи может быть, например, таким:
-
Забронировать
билет.
-
Подобрать
рейс.
-
Работать
с данными.
-
Управлять
рейсами.
-
Работать
с БД аэропорта.
Для
визуального представления актеров, вариантов использования и отношений между
ними в UML предусмотрена специальная диаграмма – диаграмма
вариантов использования. Ниже приведена диаграмма для
рассматриваемого примера:
Приведем
некоторые дополнительные соображения [3]:
-
При
таком моделировании обращают внимание на поведение системы, а не на ее
реализацию.
-
Хорошая
модель описывает основное поведение системы, не являясь слишком подробным.
-
Подобная
модель позволяет проверить, удовлетворит ли система требования заказчика.
-
Система
средних размеров может быть описана большим количеством вариантов
использования.
-
Варианты
использования могут описываться разными сценариями.
На последнем
пункте остановимся подробнее. Очевидно, название варианта использования не дает
полного представления о том, как он претворяется в жизнь. Для описания сценария
работы варианта использования UML содержит
специальные средства. Основное из них – диаграмма действия.
Диаграмма
действия
это блок-схема, которая отображает динамику в поведении системы. Заметим, что
эта диаграмма может использоваться не только для описания сценариев Варианта
использования.
Приведем
пример соответствующей диаграммы для варианта использования Бронирование
билетов в системе SRS.
6.
Структура системы и ее описание
средствами UML
В данном
разделе рассматриваются элементы UML,
предназначенные для описания структуры проектируемой программной системы. Наше
изложение устроено следующим образом: для стандартных понятий, известных из
курса ООП, мы приводим только обозначения. Для других прежде всего даем
определение и краткую характеристику. Итак, приступим.
6.1. Классы
Обозначения
модификаторов доступа:
|
+ |
public |
|
# |
protected |
|
- |
private |
6.2. Шаблоны классов
6.3. Объекты
6.4. Интерфейсы
Определимся с
тем, что мы в данном случае понимаем под Интерфейсом.
Интерфейс определяет
границу между спецификацией того, что делает абстракция, и реализацией того,
как она это делает [3].
Интерфейс – это набор
операций, используемых для специфицирования услуг, предоставляемых классом или
компонентом [3].
Смысл
использования Интерфейса состоит в отделении деталей реализации от
функциональности. Так, класс, подсистема, компонент обычно предоставляют некоторую
функциональность, которой могут пользоваться другие классы, подсистемы,
компоненты. Описание этой, доступной извне, функциональности содержится в
Интерфейсе.
Во многих
языках программирования понятие Интерфейс включено в объектную модель, что
сообразно отражается на синтаксисе (Object Pascal, Java и др.). С++, к
сожалению, не содержит понятия Интерфейс, поэтому Интерфейсы моделируются
посредством использования классов.
6.5. Пакеты
Пакет – структурная
единица для группировки элементов модели, в частности, классов.
Пакет – это способ
организации элементов модели в более крупные блоки, которыми впоследствии
позволяется манипулировать как единым целым. Хорошо спроектированный пакет
группирует семантически близкие элементы, которые имеют тенденцию изменяться
совместно [3].
6.6. Подсистемы
На этапе
проектирования системы классы и пакеты могут объединяться в подсистемы.
Подсистема
– структурная единица. Каждая подсистема имеют
свою область ответственности и реализует некоторую функциональность. Подсистема
реализует Интерфейс, который описывает ее поведение.
В рассматриваемом учебном примере SRS примерами
подсистем являются: подсистема бронирования билетов; подсистема доступа к
данным...
6.7. Компоненты
Компонент – физическая
заменяемая часть системы, совместимая с одним набором интерфейсов и
обеспечивающая реализацию какого-либо другого [3]. Компонент может
разрабатываться и тестироваться независимо от системы.
Виды
компонентов:
-
Исходные
файлы (.cpp, .h, .java…).
-
Бинарные
файлы (.dll, .ocx…).
-
Исполняемые
файлы (.exe).
По смыслу
компонент представляет собой реализацию подсистемы. На этапе проектирования мы
работаем с подсистемами. На этапе реализации – с компонентами.
6.8. Комментарии
UML предусматривает возможность написания
комментариев (заметок). Делается это следующим образом:
6.9. Отношения между элементами модели
UML поддерживает следующие виды отношений
между элементами модели:
-
Зависимость.
-
Ассоциация.
-
Обобщение
(наследование).
-
Реализация (для
Интерфейса).
Отношения
показывают наличие связей между элементами модели и семантику этих связей.
Рассмотрим
каждый из этих типов отношений.
6.9.1.
Зависимость
Зависимость – связь между
сущностями (классами, объектами). Зависимость показывает, что изменения в одной
сущности могут повлиять на другую сущность. Зависимость – не структурная связь.
Возникает через локальную, глобальную переменные или параметр метода.
TFirst
зависит от TSecond
6.9.2.
Ассоциация
Ассоциация – связь между
сущностями (классами, объектами). Ассоциация
показывает наличие структурной связи между экземплярами (объектами).
Структурная связь реализуется через поле класса. В обозначениях UML направление может быть не указано
(двусторонняя связь).
TFirst
содержит поле, связанное с
TSecond
6.9.3.
Направление и навигация
Заметим, что
наличие направления
связано с понятием Навигация. Навигация
означает, что в направлении стрелки один объект «видит» другой, в то время как
обратное не выполняется.
TFirst
видит TSecond
6.9.4.
Кратность
Кратность – способ
конкретизации характера отношения. Показывает тип отношения 1:1, 1:M, N:1, N:M.
Каждому
контейнеру соответствует M элементов.
Каждому элементу соответствует 1 контейнер.
|
Вид
кратности |
Значение |
|
*
или 0..* |
≥0 |
|
1..* |
≥1 |
|
|
обычно
0 или 1 |
|
1 |
Ровно
1 |
|
3,5..6 |
{3,5,6} |
6.9.5.
Частные случаи ассоциаций: агрегация
и композиция
Агрегация предполагает,
что 0 или более объектов одного типа включены в 1 или
более объектов другого типа.
Композиция – вариант
агрегации, в котором каждый объект второго типа может быть включен ровно
в 1 объект первого типа.
Композиция
Агрегация
6.9.6.
Обобщение (наследование)
TFirst и TSecond выведены из TSomeClass
7.
Литература
1.
И. Соммервиль. Инженерия программного обеспечения,
6 изд. – И.д. "Вильямс", 2002.
2.
Г. Буч. Объектно-ориентированный анализ
и проектирование с примерами приложений
на C++. Второе издание. – Бином, 1998.
3.
Г. Буч, Дж. Рамбо, А. Джекобсон. UML.
Руководство пользователя. – ДМК-Пресс, Питер, 2004.
4.
G. Booch, J. Rumbaugh, I. Jacobson. The Unified Modeling Language Reference Manual – Second Edition,
Addison-Wesley, 2004.
5.
www.uml.org