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

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

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

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

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

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

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

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

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

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

Является ли UML необходимым компонентом RUP? Да, безусловно. Но практика использования UML как средства описания процесса моделирования и разработки программного обеспечения не ограничивается RUP. Как и любой другой язык, UML - это всего только средство. В RUP предусмотрен ряд утилит, позволяющих довольно легко использовать UML, но их набор не ограничивается лишь продуктами IBM/Rational. Ниже приводится далеко не полный список некоторых продуктов, поддерживающих 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) - неплохая утилита для начинающих.

Отметим также некоторые продукты OpenSourse, например ArgoUML, Novosoft UML Library.

Документ, который содержит списки продуктов, поддерживающих UML, компаний-производителей, платформ, а также информацию о примерных ценах продуктов, можно найти по адресу: http://www.objectsbydesign.com/tools/umltools_byCompany.html .

Следует также отметить, что, несмотря на факт существования стандарта UML 1.3, поддерживаемые перечисленными продуктами реализации UML или обладают собственными особенностями, или не полностью следуют стандарту, поэтому при выборе средства моделирования следует обращать внимание на поддерживаемые типы диаграмм и особенности синтаксиса. Кроме того, возможности прямого и обратного проектирования (Round-Trip Engineering) в разных продуктах весьма различны. Не все вышеуказанные продукты могут поддерживать языки программирования Java, C++, CORBA IDL, поэтому следует обращать особое внимание на то, какую модель сможет сгенерировать тот или иной продукт из имеющегося у вас кода, на каком языке может быть получен код из вашей UML-модели и какого она должна быть типа.

Таблица, показывающая, какие диаграммы UML реализованы в том или ином продукте, находится по адресу: http://www.jeckle.de/umltools.htm .

Для чего применяется UML

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 являются сущности (Thing), отношения (Relationship), диаграммы (Diagram). Сущности являются ключевыми абстракциями языка, отношения связывают сущности вместе, диаграммы группируют коллекции сущностей, которые представляют интерес.

Сущности

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

классы (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). К ним относятся:

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

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

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

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

Отношения

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

зависимость (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).

Представление с точки зрения прецедентов (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);

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

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

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

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

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

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

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

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

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

Продолжение следует.

Унифицированный язык моделирования (UML) в настоящий момент является стандартом де-факто при описании (документирования) результатов проектирования и разработки объектно-ориентированных систем. Начало разработки UML было положено в 1994 г. Гради Бучем и Джеймсом Рамбо, работавшим в компании Rational Software. Осенью 1995 г. к ним присоединился Ивар Якобсон и в октябре того же года была выпущена предварительная версия 0.8 унифицированного метода (англ. Unified Method). С этого времени было выпущено несколько версий спецификации UML, две из которых носят статус международного стандарта:

UML 1.4.2 – "ISO/IEC 19501:2005. Информационные технологии. Открытая распределительная обработка. Унифицированный язык моделирования (UML). Версия 1.4.2" (англ. "Information technology. Open distributed processing. Unified modeling language (UML). Version 1.4.2");

UML 2.4.1 – "ISO/IEC 19505-1:2012. Информационные технологии. Унифицированный язык моделирования группы по управлению объектами (OMG UML). Часть 1. Инфраструктура" (англ. "Information technology -- Object Management Group Unified Modeling Language (OMG UML) - Part 1: Infrastructure") и "ISO/IEC 19505-2:2012. Информационные технологии. Унифицированный язык моделирования группы по управлению объектами (OMG UML). Часть 2. Сверхструктура" (англ. "Information technology -- Object Management Group Unified Modeling Language (OMG UML) - Part 2: Superstructure").

Последнюю официальную спецификацию языка можно найти на сайте www.omg.org .

Общая структура UML показана на следующем рисунке .

Рис. 11.1. Структура UML

11.2. Семантика и синтаксис UML

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

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

Таким образом, применительно к UML, семантика и синтаксис определяют стиль изложения (построения моделей), который объединяет естественный и формальный языки для представления базовых понятий (элементов модели) и механизмов их расширения.

11.3. Нотация UML

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

В UML определено три типа сущностей :

Структурная – абстракция, являющаяся отражением концептуального или физического объекта;

Группирующая – элемент, используемый для некоторого смыслового объединения элементов диаграммы;

Поясняющая (аннотационная) – комментарий к элементу диаграммы.

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

Таблица 11.1. Сущности

Тип	Наименование	Обозначение	Определение (семантика)
Структурная	(class)		Множество объектов, имеющих общую структуру и поведение
	(object)		Абстракция реальной или воображаемой сущности с четко выраженными концептуальными границами, индивидуальностью (идентичностью), состоянием и поведением. С точки зрения UML объекты являются экземплярами класса (экземплярами сущности)
	(actor)	Инженер службы пути	Внешняя по отношению к системе сущность, которая взаимодействует с системой и использует ее функциональные возможности для достижения определенных целей или решения частных задач. Таким образом актер – это внешний источник или приемник информации
	(use case)		Описание выполняемых системой действий, которая приводит к значимому для актера результату
	(state)		Описание момента в ходе жизни сущности, когда она удовлетворяет некоторому условию, выполняет некоторую деятельность или ждет наступления некоторого события
	Кооперация (collaboration)		Описание совокупности экземпляров актеров, объектов и их взаимодействия в процессе решения некоторой задачи
	(component)		Физическая часть системы (файл), в том числе модули системы, обеспечивающие реализацию согласованного набора интерфейсов
	(interface)	iРасчет	Совокупность операций, определяющая сервис (набор услуг), предоставляемый классом или компонентом
	(node)		Физическая часть системы (компьютер, принтер и т. д.), предоставляющая ресурсы для решения задачи
Группирующая	(package)		Общий механизм группировки элементов. В отличие от компонента, пакет – чисто концептуальное (абстрактное) понятие. Частными случаями пакета являются система и модель
	(fragment)		Область специфического взаимодействия экземпляров актеров и объектов
	(activity partition)		Группа операций (зона ответственности), выполняемых одной сущностью (актером, объектом, компонентом, узлом и т.д.)
	(interruptible activity region)		Группа операций, обычная последовательность выполнения которых может прервана в результате наступления нестандартной ситуации
Поясняющая	Примечание (comment)		Комментарий к элементу. Присоединяется к комментируемому элементу штриховой линией

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

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

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

Таблица 11.3. Отношения

Наименование	Обозначение	Определение (семантика)
Ассоциация (association)		Отношение, описывающее значимую связь между двумя и более сущностями. Наиболее общий вид отношения
Агрегация (aggregation)		Подвид ассоциации, описывающей связь "часть"–"целое", в котором "часть" может существовать отдельно от "целого". Ромб указывается со стороны "целого". Отношение указывается только между сущностями одного типа
Композиция (composition)		Подвид агрегации, в которой "части" не могут существовать отдельно от "целого". Как правило, "части" создаются и уничтожаются одновременно с "целым"
Зависимость (dependency)		Отношение между двумя сущностями, в котором изменение в одной сущности (независимой) может влиять на состояние или поведение другой сущности (зависимой). Со стороны стрелки указывается независимая сущность
Обобщение (generalization)		Отношение между обобщенной сущностью (предком, родителем) и специализированной сущностью (потомком, дочкой). Треугольник указывается со стороны родителя. Отношение указывается только между сущностями одного типа
Реализация (realization)		Отношение между сущностями, где одна сущность определяет действие, которое другая сущность обязуется выполнить. Отношения используются в двух случаях: между интерфейсами и классами (или компонентами), между вариантами использования и кооперациями. Со стороны стрелки указывается сущность, определяющее действие (интерфейс или вариант использования)

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

- * – любое количество экземпляров, в том числе и ни одного;

Целое неотрицательное число – кратность строго фиксирована и равна указанному числу (например: 1, 2 или 5);

Диапазон целых неотрицательных чисел "первое число.. второе число" (например: 1..5, 2..10 или 0..5);

Диапазон чисел от конкретного начального значения до произвольного конечного "первое число.. *" (например: 1..*, 5..* или 0..*);

Перечисление целых неотрицательных чисел и диапазонов через запятую (например: 1, 3..5, 10, 15..*).

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

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

Таблица 11.4. Механизмы расширения

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

a) стандартное обозначение		б) стандартное обозначение с текстовым стереотипом		в) графический стереотип

Рис. 11.2. Примеры стандартного и стереотипного отображения класса

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

Таблица 11.5. Диаграммы

Стандарт UML 2.x определяет также дополнительные, узкоспециализированные диаграммы:

Диаграмму объектов (object diagram) - аналогична , но вместо классов отображаются объекты;

Диаграмму синхронизации (timing diagram) - описывает состояния объекта с течением времени;

Композитную структурную диаграмму (composite structure diagram) - описывает порты (включая интерфейсы) класса для взаимодействия с другими классами;

Профильную диаграмму (profile diagram) - аналогична с описанием классов, входящих в них;

Обзорную диаграмму взаимодействия (interaction overview diagram) - аналогична , но со скрытыми фрагментами взаимодействия (фрагментами с меткой ref). Представляет собой контекстную (концептуальную) , элементы которой будут конкретизированы на отдельных диаграммах декомпозиции.

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

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

Таблица 11.6. Связь моделей и диаграмм

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

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

4. Дайте определение понятию " ".

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

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

Диаграмма использования (use case diagram) ‒ это наиболее общее представление функционального назначения системы.

Диаграмма использования призвана ответить на главный вопрос моделирования: что делает система во внешнем мире?

На диаграмме использования применяются два типа основных сущностей: варианты использования 1 и действующие лица 2 , между которыми устанавливаются следующие основные типы отношений:

• ассоциация между действующим лицом и вариантом использования 3 ;
• обобщение между действующими лицами 4 ;
• обобщение между вариантами использования 5 ;
• зависимости (различных типов) между вариантами использования 6 .

На диаграмме использования, как и на любой другой, могут присутствовать комментарии 7 . Более того, это настоятельно рекомендуется делать для улучшения читаемости диаграмм.

Основные элементы нотации, применяемые на диаграмме использования, показаны ниже. Детальное описание приведено в разделе 2.2 .

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

Диаграмма классов (class diagram) ‒ основной способ описания структуры системы.

Это не удивительно, поскольку UML в первую очередь объектно-ориентированный язык, и классы являются основным (если не единственным) "строительным материалом".

На диаграмме классов применяется один основной тип сущностей: классы 1 (включая многочисленные частные случаи классов: интерфейсы, примитивные типы, классы-ассоциации и многие другие), между которыми устанавливаются следующие основные типы отношений:

• ассоциация между классами 2 (с множеством дополнительных подробностей);
• обобщение между классами 3 ;
• зависимости (различных типов) между классами 4 и между классами и интерфейсами.

Некоторые элементы нотации, применяемые на диаграмме классов, показаны ниже. Детальное описание приведено в главе 3 .

1.5.3. Диаграмма автомата

Диаграмма автомата (state machine diagram) ‒ это один из способов детального описания поведения в UML на основе явного выделения состояний и описания переходов между состояниями.

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

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

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

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

Диаграмма деятельности (activity diagram) ‒ способ описания поведения на основе указания потоков управления и потоков данных.

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

На диаграмме деятельности применяют один основной тип сущностей ‒ действие 1 , и один тип отношений ‒ переходы 2 (передачи управления и данных). Также используются такие конструкции как развилки, слияния, соединения, ветвления 3 , которые похожи на сущности, но таковыми на самом деле не являются, а представляют собой графический способ изображения некоторых частных случаев многоместных отношений. Семантика элементов диаграмм деятельности подробно разобрана в главе 4 . Основные элементы нотации, применяемые на диаграмме деятельности, показаны ниже.

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

Диаграмма последовательности (sequence diagram) ‒ это способ описания поведения системы на основе указания последовательности передаваемых сообщений.

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

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

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

Ось времени может быть направлена горизонтально, в этом случае считается, что время течет слева направо.

На следующем рисунке показаны основные элементы нотации, применяемые на диаграмме последовательности. Для обозначения самих взаимодействующих объектов применяется стандартная нотация ‒ прямоугольник с именем экземпляра классификатора. Пунктирная линия, выходящая из него, называется линией жизни (lifeline) 4 . Это не обозначение отношения в модели, а графический комментарий, призванный направить взгляд читателя диаграммы в правильном направлении. Фигуры в виде узких полосок, наложенных на линию жизни, также не являются изображениями моделируемых сущностей. Это графический комментарий, показывающий отрезки времени, в течении которых объект владеет потоком управления (execution occurrence) 5 или другими словами имеет место активация (activation) объекта. Составные шаги взаимодействия(combined fragment) 6 позволяют на диаграмме последовательности, отражать и алгоритмические аспекты протокола взаимодействия. Прочие детали нотации диаграммы последовательностей см. в главе 4 .

1.5.6. Диаграмма коммуникации

Диаграмма коммуникации (communication diagram) ‒ способ описания поведения, семантически эквивалентный диаграмме последовательности.

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

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

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

1.5.7. Диаграмма компонентов

Диаграмма компонентов (component diagram) ‒ показывает взаимосвязи между модулями (логическими или физическими), из которых состоит моделируемая система.

Основной тип сущностей на диаграмме компонентов ‒ это сами компоненты 1 , а также интерфейсы 2 , посредством которых указывается взаимосвязь между компонентами. На диаграмме компонентов применяются следующие отношения:

• реализации между компонентами и интерфейсами (компонент реализует интерфейс);
• зависимости между компонентами и интерфейсами (компонент использует интерфейс) 3 .

На рисунке показаны основные элементы нотации, применяемые на диаграмме компонентов. Детальное описание приведено в главе 3 .

1.5.8. Диаграмма размещения

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

Таким образом, на диаграмме размещения, по сравнению с диаграммой компонентов, добавляется два типа сущностей: артефакт 1 , который является реализацией компонента 2 и узел 3 (может быть как классификатор, описывающий тип узла, так и конкретный экземпляр), а также отношение ассоциации между узлами 4 , показывающее, что узлы физически связаны во время выполнения.

На рисунке показаны основные элементы нотации, применяемые на диаграмме размещения. Для того чтобы показать, что одна сущность является частью другой, применяется либо отношение зависимости «deploy» 5 , либо фигура одной сущности помещается внутрь фигуры другой сущности 6 . Детальное описание диаграммы приведено в главе 3 .

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

Зачем она нужна?

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

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

Также стоит отметить, что есть несколько видов таких диаграмм.

Диаграмма классов

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

Стоит отметить тот факт, что есть несколько точек зрения на построение таких диаграмм в зависимости от того, каким образом они будут использоваться:

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

Диаграмма компонентов

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

Диаграмма композитной/составной структуры

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

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

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

Диаграмма развертывания

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

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

Диаграмма объектов

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

Диаграмма пакетов

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

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

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

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

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

Диаграмма автомата

Этот вид называется и несколько иначе - диаграмма состояний UML. Имеет представленный конечный автомат с простыми и композитными состояниями, а также переходами.

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

В качестве аналогов таких диаграмм могут использоваться так называемые дракон-схемы.

Диаграммы сценариев использования

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

Если диаграмма вариантов использования UML используется в процессе моделирования системы, то аналитик собирается:

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

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

Коммуникации

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

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

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

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

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

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

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

Диаграмма сотрудничества

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

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

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

Это диаграммы языка UML, которые относятся к разновидности диаграмм деятельности и включают в себя одновременно элементы Sequence и конструкции потока управления.

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

Диаграмма синхронизации

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

В чем преимущества?

Стоит отметить несколько преимуществ, которыми отличается UML диаграмма пользования и другие:

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

Недостатки

Несмотря на то что построение UML-диаграмм отличается массой своих плюсов, довольно часто их и критикуют за следующие недостатки:

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

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