Объектно-ориентированное проектирование

Методы проектирования основное внимание направляют на правильное и эффективное структурирование сложных систем.

Определим объектно-ориентированное проектирование следующим образом:

Объектно-ориентированное проектирование ‒ это методология проектирования, соединяющая в себе процесс объектной декомпозиции и приемы представления как логической и физической, так статической и динамической моделей проектируемой системы.

В данном определении содержатся две важные части: 1) OOD ведет к объектно-ориентированной декомпозиции; 2) используется многообразие приемов представления моделей, отражающих логическую (структуры классов и объектов) и физическую (архитектура моделей и процессов) структуру системы.

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

Информационные модели

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

 

Рис. 1. Схема доменов для автоматической трассировки печатных плат.

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

Объекты изображаются на информационной модели (табл. 1) вместе с характеристиками, или атрибутами.

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

Таблица 1

Домены	Трассировка печатных плат	Регистрация тенденций	Сигналы	Пользовательский интерфейс
Подсис- темы   Этапы ООА	Расположение треугольников	Прокладка проводника	Привязка к сетке	...	Регистрация тенденций	Сигналы	Управление экраном	Отображение пиктограмм
Информа-ционные модели
Модели состояний
Модели процессов

 

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

Модели состояний

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

б)

а)

Рис. 2. а) поиск пути трассировки; б) конечный вид разведённого проводника

 

Рис. 3. Модель состояния для объекта Проводник

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

 

Рис.3

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

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

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

Как только разработаны модели взаимодействия объектов для всех подсистем в домене, для описания взаимодействий событий между подсистемами может быть нарисована модель взаимодействия подсистем.

 

Модели процессов

Всё происходящее в системе содержится в действиях моделей состояний. Теперь каждое действие определяется в терминах процессов и архивов данных объектов, где процесс является фундаментальным модулем операции, а архив данных объекта соответствует данным (атрибутам) объекта в информационной модели.

Рис. 4. Диаграмма потоков данных действий для состояния Прокладка проводника

Каждое действие изображено графически на диаграмме потоков данных действий - ДПДД, как показано на рис. 4.

 

 

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

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

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

Рабочие продукты ООАП

На рис. 5 изображена информационная карта рабочих продуктов ООА. На этом рисунке видно, что схема домена и проектная матрица создаются для всей системы. Чтобы описать взаимодействие событий между различными подсистемами в пределах домена, для каждого домена создается модель взаимодействия подсистем. Большинство рабочих продуктов ООА нужны на уровне подсистем: информационная модель, модель взаимодействия объектов, модель доступа к объектам и вспомогательные таблицы, описания и списки создаются для каждой подсистемы. Ниже подсистемы находятся объекты, которые её составляют: модель состояний создается для каждого объекта и связи, которые имеют интересующее нас динамическое поведение. Действия каждой модели состояний обеспечивают следующий уровень: диаграмма потоков данных действий создается для каждого состояния каждой модели состояний. Наконец, описание процесса создается для каждого сложного процесса действия.

Рис. 5. Рабочий продукт для Автоматической Системы Разводки Печатных Плат

Литература:

1. Шлеер С., Меллор С. Объектно-ориентированный анализ: моделирование мира в состояниях: Пер. с англ. — Киев: Диалектика, 1993.

2. Буч Г. Объектно-ориентированный анализ и проектирование с примерами приложений на C++. — Невский Диалект, 1998.

3. Хингстон Д., Логхид Ф., Ирвин Р. Новый топологический автотрассировщик // ChipNews — 2002, №2(65) — С. 60—64.

 

Язык UML

Введение

Язык Unified Modelling Language (UML) можно считать результатом довольно длинной и еще не завершившейся эволюции методологий моделирования и дизайна.

В 90-х годах наиболее популярными были три объектно-ориентированных подхода:

§ OMT (автор Джеймс Рамбо), сильной стороной которого является анализ, а слабой ‒ дизайн;

§ OODA (автор Гради Буч) ‒ сильная сторона этого языка ‒ дизайн, а слабая ‒ анализ;

§ OOSE (автор Айвар Якобсон) ‒ сильной стороной данного языка является анализ поведения (behavior analysis), однако в остальных областях он достаточно слаб.

В результате соперничества этих методов авторы вышеперечисленных методологий создали унифицированный язык моделирования UML (рис. 1), который унаследовал присутствовавшие в других языках элементы. Далее приведена оригинальная терминология заимствованных/унаследованных элементов языка этой методологии ‒ дело в том, что сейчас существует несколько вариантов переводов этих терминов на русский язык.

 

Рис. 1. UML и его предшественники

 

 

Данная унификация преследовала три основные цели:

§ моделирование системы, начиная с концепции и заканчивая исполняемым модулем, с применением объектно-ориентированных методик;

§ разрешение проблем масштабирования в сложных системах;

§ создание языка моделирования, используемого и человеком, и компьютером.

Официальной датой начала работ по UML считают октябрь 1994 года, когда Рамбо перешел в компанию Rational (ныне Rational ‒ одно из подразделений корпорации IBM). Последним стандартом этого языка является версия UML1.3, вышедшая в 1999 году.

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

UML ‒ это язык визуализации. Написание моделей на UML преследует одну простую цель ‒ облегчение процесса передачи информации о системе. За каждым символом UML стоит строго определенная семантика, что позволяет избегать ошибок интерпретации (ответы на вопросы типа «а что имел в виду разработчик Х, когда он описал иерархию классов Y…» и т.п. будут достаточно прозрачны).

UML ‒ это язык спецификаций и точных определений. В этом смысле моделирование на UML означает построение моделей, которые точны, недвусмысленны и полны.

UML ‒ это язык конструирования. UML не является визуальным языком программирования, но модели в терминах UML могут быть отображены на определенный набор объектно-ориентированных языков программирования. UML предоставляет возможности прямого (существующая модель ® новый код) и обратного (существующий код ® новая модель) проектирования. Достаточно часто средства UML-моделирования реализуют отображения UML-моделей в коде на языках Java, C++, CORBA, VB, Smalltalk.

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

 

 

Структура языка UML

Язык UML имеет сложную иерархическую структуру.

 

 

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

Средства UML-моделирования

Ниже приводится далеко не полный список некоторых продуктов, поддерживающих UML:

§ Rational Rose (Rational Software, Windows 98/NT/2000/XP, Linux Red Hat 6.2, 7.0, Solaris 2.5.1, 2.6, 7, 8, HP-UX 10.20, 11.0, 11.i);

§ Microsoft Visual Studio.NET Enterprise Architect, Microsoft Visio (Microsoft, платформы: Windows 98/NT/2000/XP/Server 2003);

§ Describe Enterprise (Embarcadero technologies, платформы: Windows 98/NT/2000/XP);

§ семейство продуктов Together (Borland, платформы: Windows 98/NT/2000/XP, Linux, Solaris);

§ Bold for Delphi (Borland, платформы: Windows 98/NT/2000/XP);

§ MagicDraw (Magic, Inc., платформы: Windows 98/Me/NT/2000/XP, Solaris, OS/2, Linux, HP-UX, AIX, Mac OS);

§ QuickUML (ExcelSoftware, платформы: Windows 98/NT/2000/XP) ‒ неплохая утилита для начинающих.

 

Отметим также некоторые продукты Open Sourse, например Argo UML, Novo soft UML Library.

Элементы языка

Основными элементами UML являются сущности (Thing), отношения (Relationship), диаграммы (Diagram). Сущности являются ключевыми абстракциями языка, отношения связывают сущности вместе, диаграммы группируют коллекции сущностей, которые представляют интерес.

Сущности

Структурные сущности являются существительными языка (рис. 2). К ним относятся:

 

Рис. 2. Структурные сущности UML

 

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

§ интерфейсы (Interface) ‒ это набор операций, которые определяют сервис класса или компоненты. Интерфейс графически изображается в виде круга и, как правило, присоединяется к классу или к компоненту, который реализует данный интерфейс;

§ кооперации (Collaboration) ‒ определяют взаимодействие и служат для объединения ролей и других элементов, которые взаимодействуют вместе так, что получающееся в результате поведение объекта оказывается большим, чем просто сумма всех элементов. Изображается в виде эллипса с пунктирной границей;

§ прецеденты (Use case) ‒ описание набора последовательностей действий, которые выполняются системой и имеют значение для конкретного действующего лица (Actor). Прецеденты изображаются в виде эллипса и используются для структурирования поведенческих сущностей в модели;

§ активные классы (Active class) ‒ это классы, чьими экземплярами являются активные объекты, которые владеют процессом или потоком управления и могут инициировать управляющее воздействие. Стереотипами конкретного класса являются процесс (Process) и поток (Thread). Графически такой класс изображается как класс с жирной границей;

§ компоненты (Component) ‒ это физически заменяемые части системы, обеспечивающие реализацию ряда интерфейсов. Компонент ‒ это физическое представление таких логических элементов, как классы, интерфейсы и кооперации. Предметная область компонентов относится к реализации. Изображаются компоненты в виде прямоугольника с ярлыками слева и, как правило, имеют только имя и примечание;

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

Данные перечисленных семи типов объектов являются базовыми структурными объектами UML. Существуют также вариации данных объектов, такие как действующие лица (Actor), сигналы (Signal), утилиты (Utility ‒ вид класса), процессы и нити (Process и Thread ‒ виды активного класса), приложения (Application), документы (document), файлы (File), библиотеки (Library), страницы (Page), таблицы (Table).

Поведенческие сущности ‒ это динамические части моделей UML (рис. 3). К ним относятся:

 

Рис. 3. Поведенческие сущности UML

 

§ взаимодействия (Interaction) ‒ включают набор сообщений, которыми обмениваются указанные объекты с целью достижения указанной цели. Взаимодействие описывается в контексте кооперации и изображается направленной линией, маркируется именем операции сверху;

§ автоматы (State machine) ‒ спецификации поведения, представляющие собой последовательности состояний, через которые проходит в течение своей жизни объект, или взаимодействие в ответ на происходящие события (а также ответные действия объекта на эти события). Автомат прикреплен к исходному элементу (классу, кооперации или методу) и служит для определения поведения его экземпляров. Изображается автомат как прямоугольник с закругленными углами.

Группирующие сущности ‒ это организационные составляющие моделей UML. К ним относятся пакеты (Package) ‒ обобщенный механизм для организации элементов в группы. Структурные, поведенческие, группирующие сущности могут быть помещены в пакет. Пакеты являются чисто концептуальными сущностями ‒ в отличие от компонентов, существующих во время исполнения программы. Изображается пакет как папка с ярлыком сверху и, как правило, имеет только имя.

Аннотационные сущности ‒ это пояснительные составляющие моделей UML, к которым относятся примечания (Note) ‒ пояснительные элементы языка (рис. 4). Они содержат текст комментария, изображаются в виде прямоугольника с загнутым уголком страницы.

 

 

Рис. 4. Аннотационные сущности UML

Отношения

К базовым отношениям между объектами, которые позволяют строить блоки UML, можно отнести следующие (рис. 5):

 

 

Рис. 5. Отношения UML

 

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

абстракция (Abstraction) ‒ представляет собой изменение уровня абстрактности для некоторого понятия. Как правило, один из элементов, более абстрактный, а второй ‒ более конкретный, хотя возможны ситуации, когда оба элемента являются двумя возможными вариантами понятия, существующими на одном уровне абстракции. К зависимости абстракции относятся следующие стереотипы (в порядке возрастания специфичности отношений): трассировать (Trace), уточнять (Refine), реализовать (есть собственная нотация) и выводить (Derive),

связывание (Binding) ‒ связывает элемент с шаблоном. Аргументы, необходимые для параметров шаблона, прикреплены к зависимости связывания в виде списка;

комбинирование (Combination) ‒ соотносит две части описания классификатора (любой элемент модели, описывающий определенные черты структуры и поведения системы), чтобы получить полное описание элемента;

разрешение (Permission) ‒ зависимость (всегда изображается в виде особого стереотипа), связывающая тот или иной пакет (или класс) с другим пакетом (или классом), которому он предоставляет разрешение использовать свое содержимое. Стереотипами зависимости разрешения являются: быть доступным (Access), быть дружественным (Friend) и импортировать (Import);

использование (Usage) ‒ описывает ситуацию, когда одному элементу для правильной реализации или функционирования требуется присутствие другого элемента. К стереотипам этого вида зависимости относятся: вызывать (Call), создать экземпляр (Instantiate), параметр (Parameter) и отправить (Send);

ассоциация (Association) ‒ структурное отношение, описывающее множество связей между объектами классификаторов, где связь (Link) ‒ это соединение между объектами, которое описывает связи между их экземплярами. Ассоциации являются как бы клеем, который связывает систему воедино. Без ассоциаций мы имели бы просто некоторое количество классов, не способных взаимодействовать друг с другом. У ассоциации может быть имя, однако основную информацию об ассоциации следует искать у ее полюсов, где описывается, каким образом каждый объект участвует в ассоциации: у ассоциации есть список, состоящий из двух или более полюсов ассоциации: каждый из них определяет роль, которую играет данный классификатор в этой ассоциации. Один и тот же классификатор может играть несколько ролей, которые не являются взаимозаменяемыми. Каждый полюс ассоциации описывает свойства, применимые к конкретному объекту этой ассоциации, например сколько раз один объект может появляться в связях (множественность).

 

Некоторые свойства (такие как допустимость навигации) применимы только к бинарным ассоциациям, хотя большинство свойств относится и к бинарным, и к n-арным ассоциациям;

обобщение (Generalization) ‒ это отношение специализации /обоб-щения, при котором объекты специализированного элемента (потомка ‒ Child) можно подставить вместо объектов обобщенного элемента (родителя, предка ‒ Parent). В случае обобщения классов прямой предок может именоваться суперклассом, а прямой потомок ‒ подклассом;

реализация (Realization) ‒ отношение между спецификацией и ее программной реализацией; указание на то, что поведение наследуется без структуры.

Мы перечислили четыре основных отношения. В UML также существуют их варианты: уточнение (Refinement), трассировка (Trace), включение (Include), расширение (Extend).

Диаграммы UML

Визуализация представления проектируемой системы с различных точек зрения в UML реализована посредством диаграмм ‒ проекций системы. Диаграмма (Diagram) ‒ это графическое представление множества элементов, которое изображается в виде связного графа с вершинами (сущностями) и ребрами (отношениями).

Чаще всего UML рассматривает систему с пяти взаимосвязанных точек зрения (рис. 6).

 

Рис. 6. Моделирование архитектуры системы

 

Представление с точки зрения прецедентов (Use case view) включает пользовательские истории, описывающие систему с точки зрения конечного пользователя, аналитика, тестера. Это представление не определяет структуру программного обеспечения, а существует для передачи общего представления о системе. В UML это отображается посредством диаграмм прецедентов (Use case diagram), динамический аспект представлен в диаграммах взаимодействий (Interaction diagram), состояний (Statechart diagram), активности (Activity diagram).

Представление с точки зрения дизайна (Design view) включает классы, интерфейсы и кооперации, которые формируют словарь задачи и ее решение. Данное представление в первую очередь осуществляет поддержку функциональных требований к системе, значение сервисов, которые система должна предоставить конечному пользователю. В UML это отображается посредством диаграмм классов (Class diagram) и объектов (Object diagram), динамический аспект отображается в диаграммах взаимодействий, состояний, активности.

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

Представление с точки зрения реализации (Implementation view) включает компоненты и файлы, используемые при сборке системы. Подобное представление в первую очередь относится к управлению конфигурациями (Configuration management) релизов продукта. Статический аспект в UML отображен диаграммой компонентов (Component diagram), а динамический ‒ диаграммами взаимодействий, состояний, активности.

Представление с точки зрения внедрения (Deployment view) включает узлы и их взаимодействие ‒ они определяют аппаратную топологию, на которой выполняется программное обеспечение. Это представление в первую очередь относится к распространению, доставке, установке компонентов, из которых строится физическая система. Статический аспект в UML отображается диаграммой внедрения (Deployment diagram), а динамический ‒ диаграммами взаимодействий, состояний, активности.

Ниже приведены определения и примеры диаграмм:

§ диаграмма классов (Class diagram) ‒ структурная диаграмма, на которой показано множество классов, интерфейсов, коопераций и отношений между ними (рис. 7);

Рис. 7. Диаграмма классов

§ диаграмма объектов (Object diagram) ‒ структурная диаграмма, на которой показано множество объектов и отношений между ними. Ее можно считать особым случаем диаграммы классов. Инструментам моделирования не нужно поддерживать отдельный формат для диаграмм объектов. На них изображены объекты, поэтому диаграмма классов, на которой нет классов, но есть принадлежащие им объекты, может считаться диаграммой объектов;

§ диаграмма прецедентов (Use case diagram) ‒ диаграмма поведения, на которой показано множество прецедентов и актеров, а также отношений между ними (рис. 8);

 

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

 

Диаграммы взаимодействий (Interaction diagram):

§ диаграмма последовательностей (Sequence diagram) ‒ диаграмма поведения, на которой показано взаимодействие и подчеркнута временная последовательность событий (рис. 9);

 

 

Рис. 9. Диаграмма последовательностей

§ диаграмма кооперации (Collaboration diagram) ‒ диаграмма поведения, на которой показано взаимодействие и подчеркнута структурная организация объектов, посылающих и принимающих сообщения (рис. 10);

Рис. 10. Диаграмма кооперации

§ диаграмма состояний (Statechart diagram) ‒ диаграмма поведения, на которой показан автомат и подчеркнуто поведение объектов с точки зрения порядка получения событий (рис. 11);

 

Рис. 11. Диаграмма состояний

§ диаграмма активности (Activity diagram) ‒ диаграмма поведения, на которой показан автомат и подчеркнуты переходы потока управления от одной деятельности к другой (рис. 12);

 

Рис. 12. Диаграмма активности

§ диаграмма компонентов (Component diagram) ‒ диаграмма, на которой изображена организация некоторого множества компонентов и зависимости между ними, ‒ относится к статистическому виду системы (рис. 13);

 

Рис. 13. Диаграмма компонентов

§ диаграмма топологии системы (Deployment diagram) ‒ структурная диаграмма, на которой показаны узлы и отношения между ними (рис. 14).

 

Рис. 14. Диаграмма топологии системы

Пример

Рассмотрим пример использования языка UML с помощью диаграммы последовательностей и Microsoft Visio 2003.

Выводы

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

§ Само собой разумеется, что знание UML не гарантирует построения разумных и понятных моделей, хотя и является для этого необходимым.

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

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

1. Чен П.П. Модель “сущность-связь” – шаг к единому представлению данных. СУБД, N3, 1995 г.

2. Вендров А.М. CASE-технологии. Современные методы и средства проектирования информационных систем. М., Финансы и статистика, 1998.

3. Вендров А.М. Проектирование программного обеспечения экономических информационных систем. М., Финансы и статистика, 2000.

4. Фаулер М., Скотт К. UML в кратком изложении. Применение стандартного языка объектного моделирования. М., Мир, 1999.

5. Буч Г. Объектно-ориентированный анализ и проектирование с примерами приложений на C++. 2-е изд. М., Издательство Бином, СПб., Невский диалект, 1999.

6. Буч Г., Рамбо Д., Джекобсон А. Язык UML: руководство пользователя. М., ДМК, 2000.

7. http://www.objectsbydesign.com/tools/umltools_byCompany.html.

8. http://www.jeckle.de/umltools.htm.