Если у вас за плечами имеется хотя бы базовый курс программирования, вы наверняка слышали о диаграммах UML. Но как обстоят дела на практике? Поскольку диаграммы UML отнимают много времени и при том довольно быстро устаревают в условиях гибкой среды, многие разработчики совсем про них позабыли.
А зря: наглядная документация в виде диаграмм UML дает ряд преимуществ — от адаптации новых сотрудников до беглого обзора системы с другими участниками проекта без пустой траты времени на совещаниях.
Lucidchart — незаменимый инструмент в работе с диаграммами UML, а эта статья познакомит вас с их разновидностями или поможет освежить полученные прежде знания. Здесь же вы найдете шаблоны и примеры для разных ситуаций — все их можно применить в Lucidchart.
Что такое диаграммы UML?
UML (с английского аббревиатура расшифровывается как Unified Modeling Language — унифицированный язык моделирования) — это способ наглядно описать архитектуру, проектирование и реализацию комплексных программных систем. Код типичного приложения включает в себя тысячи строк, за связями и иерархиями которых очень непросто уследить. С помощью диаграмм UML структуру программы можно разделить на компоненты и подкомпоненты.
Информатика. 8 класс. Разработка алгоритма /08.04.2021/
Для чего нужны диаграммы UML?
UML — стандартизированный язык моделирования. Он совместим с разными языками программирования и процессами разработки, а потому большинству программистов не составит труда понять и применить его на практике.
Хотя многие программисты боятся диаграмм как огня, схематизация всё же очень очень полезна в гибкой разработке и позволяет сосредоточиться на проекте и получить больше отдачи. Вместо того чтобы рассуждать, как здорово было бы воспользоваться диаграммами UML, просто включите их в документацию в качестве основного компонента. Диаграммы UML помогут разработчикам:
- оперативно ввести в курс дела новых сотрудников или коллег из других отделов;
- легко сориентироваться в исходном коде;
- основательно спланировать новые функции, прежде чем взяться за программирование;
- доступным языком объяснить материал аудиториям с разными уровнями технической подготовки.
Безусловно, от схем, которые не развиваются вместе с проектом, мало толку, поэтому документацию необходимо постоянно обновлять. Поскольку Lucidchart работает в «облаке», это уже большой плюс. Lucidchart позволяет генерировать диаграммы последовательностей UML непосредственно из текстовой разметки, открывая вам широкие возможности для автоматизации и гибкой работы.
Какие разновидности выделяют в диаграммах UML?
Тем, кто мало знаком с диаграммами UML, может показаться, что их разновидностям нет числа, но это не так. Стандарты UML признают 13 видов диаграмм, которые делятся на две группы, как указано ниже.
Структурные диаграммы UML
Структурные диаграммы UML, как видно из названия, иллюстрируют структуру системы, включая ее классы, объекты, пакеты, компоненты и другие элементы, а также установленные между ними связи.
Диаграмма классов
Поскольку многие проекты опираются на объектно-ориентированное программирование, где от разработчика требуется описание типов возможных функций, диаграммы классов — самый популярный вариант UML. На диаграмме классов приводится статичная структура системы, включая классы, их атрибуты, поведение и взаимосвязи.
Класс обозначается прямоугольником из трех блоков, расположенных один над другим: в верхнем блоке обязательно указывается имя класса, а в остальных двух — дополнительная информация: атрибуты, операции и поведение.
Диаграмма компонентов
Диаграмма компонентов — по сути, более подробная версия диаграммы классов: и в той, и в другой действуют одни и те же правила. Диаграмма компонентов позволяет разбить комплексную систему на более мелкие составляющие и наглядно продемонстрировать установленные между ними связи.
Диаграмма развертывания
Диаграммы развертывания иллюстрируют, как происходит развертывание программы на аппаратных компонентах системы. Чаще всего такими диаграммами пользуются проектировщики систем — для наглядной оценки производительности, масштабируемости, надежности и портативности. Поскольку на этих диаграммах показано, как аппаратные компоненты расположены относительно друг друга, с их помощью проще уследить за всей системой и не упустить из виду ни один компонент в ходе развертывания.
Диаграмма композитной структуры
Диаграммы этого типа наглядно описывают внутреннюю структуру классификатора. С их помощью также можно проиллюстрировать кооперацию или взаимодействие классификатора с собственной средой через порты. А еще диаграммы композитной структуры позволяют без труда обрисовать внутренние компоненты любого аппаратного обеспечения, чтобы ясно представить механизмы его работы.
Диаграмма объектов
Диаграммы объектов дают нам примеры того, как структуры данных выглядят в конкретный момент времени. Если статичную структуру удобно представить в виде диаграммы классов, то диаграммы объектов, как контрольные примеры, позволяют судить, все ли ее компоненты на месте. Из диаграммы объектов также можно почерпнуть полезную информацию об элементах модели и их ссылках.
Диаграмма пакетов
Диаграммы пакетов наглядно демонстрируют зависимости между пакетами в составе системы. Пакет изображается в виде папки и применяется для организации элементов модели (например, классов или сценариев использования) в группы.
Поведенческие диаграммы UML
Диаграммы этой категории иллюстрируют поведение системы и ее взаимодействие с пользователями, другими системами и прочими сущностями.
Временна́я диаграмма
Временны́е диаграммы часто называют «диаграммами последовательностей наоборот», а их задача заключается в том, чтобы показать, как объекты взаимодействуют между собой в определенный период времени. Эти диаграммы позволяют оценить, сколько времени занимает каждый этап процесса, и выявить участки для доработки.
Диаграмма обзора взаимодействия
Эти диаграммы наглядно описывают движение потока управления между взаимодействующими узлами. К последним относятся начальные узлы, конечные узлы потока или деятельности, а также узлы решений, слияния, разделения и соединения.
Диаграмма коммуникации
Диаграммы коммуникации (раньше они назывались диаграммами кооперации) показывают связи между объектами. По этим диаграммам можно судить, как объекты взаимодействуют друг с другом посредством сообщений в пределах архитектуры системы. Здесь же можно рассмотреть альтернативные варианты в рамках сценариев использования или операций, где требуется взаимодействие разных объектов.
Диаграмма состояний
Диаграммы состояния, если объяснять в двух словах, иллюстрируют состояния и переходы. Под «состоянием» подразумевается то или иное сочетание данных, которое способен содержать объект, а на самой диаграмме можно показать не только все возможные состояния, но и способы перехода объекта из одного состояния в другое.
Схема сценариев использования
Диаграммы сценариев использования показывают, как пользователи (которые называются «агентами» и обозначаются в виде человечков-палочек) взаимодействуют с системой. Диаграммы этого типа служат обобщенной моделью связей между агентами и системами и помогут вам объяснить устройство системы даже аудитории без особой технической подготовки.
Диаграмма последовательностей
Диаграммы последовательностей, которые иногда также называют диаграммами (или сценариями) событий, показывают, в каком порядке происходит взаимодействие между объектами. С помощью таких диаграмм довольно легко составлять незамысловатые сценарии рабочих циклов.
Диаграмма активности
На диаграммах активности можно показать разные этапы реализации сценария использования. Действия (или «активности») могут следовать одно за другим, ответвляться друг от друга либо разворачиваться одновременно. Таким образом, система предстает перед нами в динамике, а диаграммы активности также могут пригодиться в моделировании бизнес-процессов.
Если вам не хватает вдохновения, предлагаем вашему вниманию полную статью с примерами и шаблонами диаграмм UML.
Эти шаблоны послужат отличной отправной точкой для работы, а также лишний раз докажут основной тезис нашей публикации: диаграммы UML должны быть не факультативным дополнением, а обязательной составляющей документации для любого проекта в гибкой среде.
Как создать диаграмму UML
Диаграммы UML подчиняются конкретному набору правил и требуют применения стандартных фигур, поэтому освоение каждой их разновидности отнимает массу времени. К счастью, мы подготовили для вас серию доступных уроков, где всё, начиная с диаграмм классов, разложено по полочкам и разбито на простые шаги.
UML — в массы!
Пускаться в одиночное плавание по водам UML непрактично: программисты, как правило, работают командами, поэтому советуем пригласить в этот круиз всех.
Если ваши коллеги не горят желанием внедрить диаграммы UML в свой рабочий процесс, предложите им в качестве эксперимента начать с одного проекта. Когда ваша команда собственными глазами увидит все преимущества для документации, люди начнут активнее внедрять UML в качестве обязательного компонента.
Плюс ко всему, создавать диаграммы UML в Lucidchart совсем не скучно, а очень даже полезно. Убедитесь сами с помощью наших шаблонов и библиотек фигур!
Источник: www.lucidchart.com
UML-диаграммы классов
UML – унифицированный язык моделирования (Unified Modeling Language) – это система обозначений, которую можно применять для объектно-ориентированного анализа и проектирования.
Его можно использовать для визуализации, спецификации, конструирования и документирования программных систем.
Словарь UML включает три вида строительных блоков:
Сущности – это абстракции, которые являются основными элементами модели, связи соединяют их между собой, а диаграммы группируют представляющие интерес наборы сущностей.
Диаграмма – это графическое представление набора элементов, чаще всего изображенного в виде связного графа вершин (сущностей) и путей (связей). Язык UML включает 13 видов диаграмм, среди которых на первом месте в списке — диаграмма классов, о которой и пойдет речь.
Диаграммы классов показывают набор классов, интерфейсов, а также их связи. Диаграммы этого вида чаще всего используются для моделирования объектно-ориентированных систем. Они предназначены для статического представления системы.
Большинство элементов UML имеют уникальную и прямую графическую нотацию, которая дает визуальное представление наиболее важных аспектов элемента.
Сущности
Диаграммы классов оперируют тремя видами сущностей UML:
- Структурные.
- Поведенческие.
- Аннотирующие.
Структурные сущности – это «имена существительные» в модели UML. В основном, статические части модели, представляющие либо концептуальные, либо физические элементы. Основным видом структурной сущности в диаграммах классов является класс .
Поведенческие сущности – динамические части моделей UML. Это «глаголы» моделей, представляющие поведение модели во времени и пространстве. Основной из них является взаимодействие – поведение, которое заключается в обмене сообщениями между наборами объектов или ролей в определенном контексте для достижения некоторой цели. Сообщение изображается в виде линии со стрелкой, почти всегда сопровождаемой именем операции.
Аннотирующие сущности – это поясняющие части UML-моделей, иными словами, комментарии, которые можно применить для описания, выделения и пояснения любого элемента модели. Главная из аннотирующих сущностей – примечание . Это символ, служащий для описания ограничений и комментариев, относящихся к элементу либо набору элементов. Графически представлен прямоугольником с загнутым углом; внутри помещается текстовый или графический комментарий.
Структурные сущности — классы
Класс – это описание набора объектов с одинаковыми атрибутами, операциями, связями и семантикой.
Графически класс изображается в виде прямоугольника, разделенного на 3 блока горизонтальными линиями:
- имя класса
- атрибуты (свойства) класса
- операции (методы) класса.
Для атрибутов и операций может быть указан один из трех типов видимости:
Видимость для полей и методов указывается в виде левого символа в строке с именем соответствующего элемента.
Каждый класс должен обладать именем, отличающим его от других классов. Имя – это текстовая строка. Имя класса может состоять из любого числа букв, цифр и знаков препинания (за исключением двоеточия и точки) и может записываться в несколько строк.
На практике обычно используются краткие имена классов, взятые из словаря моделируемой системы. Каждое слово в имени класса традиционно пишут с заглавной буквы (верблюжья конвенция), например Sensor (Датчик) или TemperatureSensor (ДатчикТемпературы).
Для абстрактного класса имя класса записывается курсивом.
Атрибут (свойство) – это именованное свойство класса, описывающее диапазон значений, которые может принимать экземпляр атрибута. Класс может иметь любое число атрибутов или не иметь ни одного. В последнем случае блок атрибутов оставляют пустым.
Атрибут представляет некоторое свойство моделируемой сущности, которым обладают все объекты данного класса. Имя атрибута, как и имя класса, может представлять собой текст. На практике для именования атрибута используются одно или несколько коротких существительных, выражающих некое свойство класса, к которому относится атрибут.
Можно уточнить спецификацию атрибута, указав его тип, кратность (если атрибут представляет собой массив некоторых значений) и начальное значение по умолчанию.
Статические атрибуты класса обозначаются подчеркиванием.
Операция (метод) – это реализация метода класса. Класс может иметь любое число операций либо не иметь ни одной. Часто вызов операции объекта изменяет его атрибуты.
Графически операции представлены в нижнем блоке описания класса.
Допускается указание только имен операций. Имя операции, как и имя класса, должно представлять собой текст. На практике для именования операции используются короткие глагольные конструкции, описывающие некое поведение класса, которому принадлежит операция. Обычно каждое слово в имени операции пишется с заглавной буквы, за исключением первого, например move (переместить) или isEmpty (проверка на пустоту).
Можно специфицировать операцию, устанавливая ее сигнатуру, включающую имя, тип и значение по умолчанию всех параметров, а применительно к функциям – тип возвращаемого значения.
Абстрактные методы класса обозначаются курсивным шрифтом.
Статические методы класса обозначаются подчеркиванием.
Изображая класс, не обязательно показывать сразу все его атрибуты и операции. Для конкретного представления, как правило, существенна только часть атрибутов и операций класса. В силу этих причин допускается упрощенное представление класса, то есть для графического представления выбираются только некоторые из его атрибутов. Если помимо указанных существуют другие атрибуты и операции, вы даете это понять, завершая каждый список многоточием.
Чтобы легче воспринимать длинные списки атрибутов и операций, желательно снабдить префиксом (именем стереотипа) каждую категорию в них. В данном случае стереотип – это слово, заключенное в угловые кавычки, которое указывает то, что за ним следует.
Отношения между классами
Существует четыре типа связей в UML:
- Зависимость
- Ассоциация
- Обобщение
- Реализация
Эти связи представляют собой базовые строительные блоки для описания отношений в UML, используемые для разработки хорошо согласованных моделей.
Первая из них – зависимость – семантически представляет собой связь между двумя элементами модели, в которой изменение одного элемента (независимого) может привести к изменению семантики другого элемента (зависимого). Графически представлена пунктирной линией, иногда со стрелкой, направленной к той сущности, от которой зависит еще одна; может быть снабжена меткой.
Зависимость – это связь использования , указывающая, что изменение спецификаций одной сущности может повлиять на другие сущности, которые используют ее.
Ассоциация – это структурная связь между элементами модели, которая описывает набор связей, существующих между объектами.
Ассоциация показывает, что объекты одной сущности (класса) связаны с объектами другой сущности таким образом, что можно перемещаться от объектов одного класса к другому.
Например, класс Человек и класс Школа имеют ассоциацию, так как человек может учиться в школе. Ассоциации можно присвоить имя «учится в». В представлении однонаправленной ассоциации добавляется стрелка, указывающая на направление ассоциации.
Двойные ассоциации представляются линией без стрелок на концах, соединяющей два классовых блока.
Ассоциация может быть именованной, и тогда на концах представляющей её линии будут подписаны роли, принадлежности, индикаторы, мультипликаторы, видимости или другие свойства.
Множественность ассоциации представляет собой диапазон целых чисел, указывающий возможное количество связанных объектов. Он записывается в виде выражения с минимальным и максимальным значением; для их разделения используются две точки. Устанавливая множественность дальнего конца ассоциации, вы указываете, сколько объектов может существовать на дальнем конце ассоциации для каждого объекта класса, находящегося на ближнем ее конце. Количество объектов должно находиться в пределах заданного диапазона. Множественность может быть определена как единица 1 , ноль или один 0..1 , любое значение 0..* или * , один или несколько 1..* . Можно также задавать диапазон целых значений, например 2..5 , или устанавливать точное число, например 3 . 
Агрегация – особая разновидность ассоциации, представляющая структурную связь целого с его частями. Как тип ассоциации, агрегация может быть именованной. Одно отношение агрегации не может включать более двух классов (контейнер и содержимое).
Агрегация встречается, когда один класс является коллекцией или контейнером других. Причём, по умолчанию агрегацией называют агрегацию по ссылке, то есть когда время существования содержащихся классов не зависит от времени существования содержащего их класса. Если контейнер будет уничтожен, то его содержимое — нет.
Графически агрегация представляется пустым ромбом на блоке класса «целое», и линией, идущей от этого ромба к классу «часть». 
Композиция — более строгий вариант агрегации. Известна также как агрегация по значению.
Композиция – это форма агрегации с четко выраженными отношениями владения и совпадением времени жизни частей и целого. Композиция имеет жёсткую зависимость времени существования экземпляров класса контейнера и экземпляров содержащихся классов. Если контейнер будет уничтожен, то всё его содержимое будет также уничтожено.
Графически представляется как и агрегация, но с закрашенным ромбиком. 
Третья связь – обобщение – выражает специализацию или наследование , в котором специализированный элемент (потомок) строится по спецификациям обобщенного элемента (родителя). Потомок разделяет структуру и поведение родителя. Графически обобщение представлено в виде сплошной линии с пустой стрелкой, указывающей на родителя. 
Четвертая – реализация – это семантическая связь между классами, когда один из них (поставщик) определяет соглашение, которого второй (клиент) обязан придерживаться. Это связи между интерфейсами и классами, которые реализуют эти интерфейсы. Это, своего рода, отношение «целое-часть». Поставщик, как правило, представлен абстрактным классом. В графическом исполнении связь реализации – это гибрид связей обобщения и зависимости: треугольник указывает на поставщика, а второй конец пунктирной линии – на клиента. 
Пример кода и диаграммы классов для него
Программа получает данные с датчика температуры (вводятся с консоли) — по 5 измерений для каждого из двух объектов класса TemperatureMeasure и усредняет их. Также предусмотрен класс ShowMeasure для вывода измеренных значений.
#include
using namespace std;
class Sensor int value;
public :
Sensor() < value = 0; >
void setValue( int value) < this ->value += value; >
int getValue() < return value; >
>;
class MeasureCount
int number;
static int total;
public :
MeasureCount() < number = 0; >
void increment() < number++; total++; >
int getNumber() < return number; >
static int getTotal() < return total; >
>;
int MeasureCount::total = 0;
class ITemperatureMeasure
public :
virtual void setValue() = 0;
virtual double getValue() = 0;
>;
class TemperatureMeasure : public virtual ITemperatureMeasure
private :
Sensor *h; // агрегация
MeasureCount *measure; // композиция
public :
TemperatureMeasure(Sensor *h);
int getNumber() < return measure->getNumber(); >
double getValue() < return ( double )h->getValue() / measure->getNumber(); >
void setValue()
int value;
measure->increment();
cout getNumber() cin >> value;
h->setValue(value);
>
static int getTotal() < return MeasureCount::getTotal(); >
>;
TemperatureMeasure::TemperatureMeasure(Sensor *h)
measure = new MeasureCount();
this ->h = h;
>
class ShowTemperature // зависимость
public :
static void Show(TemperatureMeasure t)
cout cout >
>;
int main()
Sensor *h1 = new Sensor();
TemperatureMeasure tc1(h1);
for ( int i=0; i tc1.setValue();
ShowTemperature::Show(tc1);
cout Sensor *h2 = new Sensor();
TemperatureMeasure tc2(h2);
for ( int i = 0; i tc2.setValue();
ShowTemperature::Show(tc2);
cout cout << «Total: » << TemperatureMeasure::getTotal() cin.get(); cin.get();
return 0;
>
Результат выполнения 
UML-диаграмма классов для приведенного выше кода будет выглядеть следующим образом: 
На диаграмме классов основным классом является класс TemperatureMeasure , который и является измерителем температуры. В качестве измеренного значения формируется среднее арифметическое всех измерений — сумма всех измерений, деленная на их количество.
Для получения измерений и их суммирования используется класс Sensor (в качестве датчика температуры). В консольной задаче сами измерения передаются в этот класс для суммирования. Класс состоит в отношении агрегации с основным классом TemperatureMeasure : мы сначала создаем объект класса Sensor , а потом передаем его в качестве параметра конструктора классу TemperatureMeasure , чтобы использовать его в качестве части класса.
Количество измерений формируется классом MeasureCount , который содержит статическое свойство total для подсчета общего измерений, а также свойство count для подсчета количества измерителей конкретного объекта TemperatureMeasure . Класс MeasureCount находится в отношении композиции с классом TemperatureMeasure : объект MeasureCount создается непосредственно при создании объекта TemperatureMeasure (в его конструкторе).
Класс ITemperatureMeasure представляет собой интерфейс класса TemperatureMeasure и является своего рода поставщиком в отношении реализации.
Наконец, класс ShowTemperature находится в отношении зависимости с классом TemperatureMeasure , поскольку реализация единственного метода Show класса ShowTemperature зависит от структуры класса TemperatureMeasure .
Комментариев к записи: 11
Источник: prog-cpp.ru
Что находится между идеей и кодом? Обзор 14 диаграмм UML
Тебе пришла крутая идея продукта, но ты не хочешь увязнуть в коде и потерять целостную картинку из-за мелких деталей? Ты вот-вот присядешь за то, что крякнул корпоративный сервер и тебе нужно набить что-то крутое и айтишное?
Этот цикл статей будет посвящен полезному, но порой ускользающему от молодой поросли знанию — диаграммам UML. И начну я его с обзора существующих диаграмм, поговорим немного об истории и зачем диаграмм должно быть так много.
UML — это сокращение от Unified Modeling Language, и, как мы знаем, он является стандартизированным языком моделирования, состоящим из интегрированного набора диаграмм, разработанных, чтобы помочь разработчикам систем и программного обеспечения в определении, визуализации, конструировании и документировании артефактов программных систем, а также, к примеру, для бизнес-моделирования.
UML представляет собой набор лучших инженерных практик, которые доказали свою эффективность в моделировании больших и сложных систем и является очень важной частью разработки объектно-ориентированного программного обеспечения.
UML использует в основном графические обозначения, чтобы выразить дизайн программных проектов. Использование UML помогает проектным группам общаться, изучать потенциальные проекты и проверять архитектурный дизайн программного обеспечения.
Происхождение UML
Цель UML — предоставить стандартную нотацию, которая может использоваться всеми объектно-ориентированными методами, а также выбрать и интегрировать лучшие элементы нотаций-предшественников. UML был разработан для широкого спектра приложений. Следовательно, он предоставляет конструкции для широкого спектра систем и видов деятельности (например, распределенных систем, анализа, проектирования и развертывания систем).
UML не возник на пустом месте, ему предшествовали несколько значимых событий, личностей и методологий. Например:
- Техника объектного моделирования OMT [James Rumbaugh 1991], которая была лучшей для анализа информационных систем с большим объемом данных.
- Booch [Grady Booch 1994] — отлично подходит для разработки и реализации. Грэди Буч много работал с языком Ада и был крупным игроком в разработке объектно-ориентированных методов для языка. Хотя метод Буча был сильным, нотация была воспринята менее хорошо, например, в его моделях преобладали формы облаков, что выглядело не очень аккуратно.
- OOSE (объектно-ориентированная программная инженерия [Ivar Jacobson 1992]) — модель, известная как модель прецедентов — это мощная методология для понимания поведения всей системы, область, где ООП традиционно была слабой.
К 1995 году создатель OOSE, Ивар Якобсон, также присоединился к Rational, и его идеи (в частности, концепция «прецедентов») были включены в новый унифицированный метод, который теперь называется Unified Modeling Language.
В противовес всем известной “Банде Четырех”, Команда Румбо, Буча и Якобсона известна как «Три Амигоса».
На UML также повлияли другие объектно-ориентированные нотации:
- Меллор и Шлаер [1998]
- Coad и Yourdon [1995]
- Вирфс-Брок [1990]
- Мартин и Оделл [1992]
Почему UML?
По мере того как стратегическая ценность программного обеспечения возрастала для многих компаний, отрасль искала методы для автоматизации производства программного обеспечения, а также для повышения качества и сокращения затрат и времени выхода на рынок.
Эти методы включают технологию компонентов, визуальное программирование, шаблоны и структуры.
Компании также ищут методы для управления сложностью систем по мере увеличения их масштаба.
В частности, они признают необходимость решения повторяющихся архитектурных проблем, таких как физическое распределение, параллелизм, репликация, безопасность, балансировка нагрузки и отказоустойчивость.
Кроме того, разработка под Web хоть и упрощает некоторые вещи, в целом, она усугубляет эти архитектурные проблемы.
Унифицированный язык моделирования (UML) был разработан для удовлетворения этих потребностей.
Основные цели дизайна UML:
- Предоставить пользователям готовый, выразительный язык визуального моделирования, чтобы они могли разрабатывать и обмениваться осмысленными моделями.
- Обеспечить механизмы расширяемости и специализации для расширения основных понятий.
- Быть независимым от конкретных языков программирования и процессов разработки.
- Обеспечить формальную основу для понимания языка моделирования.
- Поощрять рост рынка объектно-ориентированных инструментов.
- Поддержка высокоуровневых концепций разработки, таких как совместная работа, структуры, шаблоны и компоненты.
- Интегрировать лучшие практики.
Структурные диаграммы показывают статическую структуру системы и ее частей на разных уровнях абстракции и реализации, а также их взаимосвязь. Элементы в структурной диаграмме представляют значимые понятия системы и могут включать в себя абстрактные, реальные концепции и концепции реализации. Существует семь типов структурных диаграмм:
- Диаграмма составной структуры
- Диаграмма развертывания
- Диаграмма пакетов
- Диаграмма профилей
- Диаграмма классов
- Диаграмма объектов
- Диаграмма компонентов
- Диаграмма деятельности
- Диаграмма прецедентов
- Диаграмма состояний
- Диаграмма последовательности
- Диаграмма коммуникаций
- Диаграмма обзора взаимодействия
- Временная диаграмма
Диаграмма классов
Диаграмма классов — это центральная методика моделирования, которая используется практически во всех объектно-ориентированных методах. Эта диаграмма описывает типы объектов в системе и различные виды статических отношений, которые существуют между ними.
Три наиболее важных типа отношений в диаграммах классов (на самом деле их больше), это:
Ассоциация, которая представляет отношения между экземплярами типов, к примеру, человек работает на компанию, у компании есть несколько офисов.
Наследование, которое имеет непосредственное соответствие наследованию в Объектно-Ориентированном дизайне.
Агрегация, которая представляет из себя форму композиции объектов в объектно-ориентированном дизайне.
Диаграмма компонентов
На языке унифицированного моделирования диаграмма компонентов показывает, как компоненты соединяются вместе для формирования более крупных компонентов или программных систем.
Она иллюстрирует архитектуры компонентов программного обеспечения и зависимости между ними.
Эти программные компоненты включают в себя компоненты времени выполнения, исполняемые компоненты, а также компоненты исходного кода.
Диаграмма развертывания
Диаграмма развертывания помогает моделировать физический аспект объектно-ориентированной программной системы. Это структурная схема, которая показывает архитектуру системы, как развертывание (дистрибуции) программных артефактов.
Артефакты представляют собой конкретные элементы в физическом мире, которые являются результатом процесса разработки.
Диаграмма моделирует конфигурацию времени выполнения в статическом представлении и визуализирует распределение артефактов в приложении.
В большинстве случаев это включает в себя моделирование конфигураций оборудования вместе с компонентами программного обеспечения, на которых они размещены.
Диаграмма объектов
Статическая диаграмма объектов является экземпляром диаграммы класса; она показывает снимок подробного состояния системы в определенный момент времени. Разница в том, что диаграмма классов представляет собой абстрактную модель, состоящую из классов и их отношений.
Тем не менее, диаграмма объекта представляет собой экземпляр в конкретный момент, который имеет конкретный характер.Использование диаграмм объектов довольно ограничено, а именно — чтобы показать примеры структуры данных.
Диаграмма пакетов
Диаграмма пакетов — это структурная схема UML, которая показывает пакеты и зависимости между ними.
Она позволяет отображать различные виды системы, например, легко смоделировать многоуровневое приложение.
Диаграмма составной структуры
Диаграмма составной структуры аналогична диаграмме классов и является своего рода диаграммой компонентов, используемой в основном при моделировании системы на микроуровне, но она изображает отдельные части вместо целых классов. Это тип статической структурной диаграммы, которая показывает внутреннюю структуру класса и взаимодействия, которые эта структура делает возможными.
Эта диаграмма может включать внутренние части, порты, через которые части взаимодействуют друг с другом или через которые экземпляры класса взаимодействуют с частями и с внешним миром, и соединители между частями или портами. Составная структура — это набор взаимосвязанных элементов, которые взаимодействуют во время выполнения для достижения какой-либо цели. Каждый элемент имеет определенную роль в сотрудничестве.
Диаграмма профилей
Диаграмма профилей позволяет нам создавать специфичные для домена и платформы стереотипы и определять отношения между ними. Мы можем создавать стереотипы, рисуя формы стереотипов и связывая их с композицией или обобщением через интерфейс, ориентированный на ресурсы. Мы также можем определять и визуализировать значения стереотипов.
Диаграмма прецедентов
Диаграмма прецедентов описывает функциональные требования системы с точки зрения прецедентов. По сути дела, это модель предполагаемой функциональности системы (прецедентов) и ее среды (актеров).
Прецеденты позволяют связать то, что нам нужно от системы с тем, как система удовлетворяет эти потребности.
Диаграмма деятельности
Диаграммы деятельности представляют собой графическое представление рабочих процессов поэтапных действий и действий с поддержкой выбора, итерации и параллелизма.
Они описывают поток управления целевой системой, такой как исследование сложных бизнес-правил и операций, а также описание прецедентов и бизнес-процессов.
В UML диаграммы деятельности предназначены для моделирования как вычислительных, так и организационных процессов.
Диаграмма состояний
Диаграмма состояний — это тип диаграммы, используемый в UML для описания поведения систем, который основан на концепции диаграмм состояний Дэвида Харела. Диаграммы состояний отображают разрешенные состояния и переходы, а также события, которые влияют на эти переходы. Она помогает визуализировать весь жизненный цикл объектов и, таким образом, помогает лучше понять системы, основанные на состоянии.
Диаграмма последовательности
Диаграмма последовательности моделирует взаимодействие объектов на основе временной последовательности. Она показывает, как одни объекты взаимодействуют с другими в конкретном прецеденте.
Диаграмма Коммуникации
Как и диаграмма последовательности, диаграмма коммуникации также используется для моделирования динамического поведения прецедента. Если сравнивать с Диаграммой последовательности, Диаграмма коммуникации больше сфокусирована на показе взаимодействия объектов, а не временной последовательности. На самом деле, диаграмма коммуникации и диаграмма последовательности семантически эквивалентны и могут перетекать одна в другую.
Диаграмма обзора взаимодействия
Диаграмма обзора взаимодействий фокусируется на обзоре потока управления взаимодействиями. Это вариант Диаграммы деятельности, где узлами являются взаимодействия или события взаимодействия. Диаграмма обзора взаимодействий описывает взаимодействия, в которых сообщения и линии жизни скрыты. Мы можем связать «реальные» диаграммы и добиться высокой степени навигации между диаграммами внутри диаграммы обзора взаимодействия.
Временная диаграмма
Временная диаграмма показывает поведение объекта (ов) в данный период времени. По сути — это особая форма диаграммы последовательности и различия между ними состоят в том, что оси меняются местами так, что время увеличивается слева направо, а линии жизни отображаются в отдельных отсеках, расположенных вертикально.
Зачем в UML столько диаграмм?
Причина этого заключается в том, что можно взглянуть на систему с разных точек зрения ведь в разработке программного обеспечения будут участвовать многие заинтересованные стороны, такие как: аналитики, конструкторы, кодеры, тестеры, контроль качества, клиенты, технические авторы.
Все эти люди заинтересованы в различных аспектах системы, и каждый из них требует разного уровня детализации.
Например, кодер должен понимать проект системы и уметь преобразовывать проект в код низкого уровня.
Напротив, технический писатель интересуется поведением системы в целом и должен понимать, как функционирует продукт.
UML пытается предоставить язык настолько выразительным образом, что все заинтересованные стороны могут извлечь выгоду, как минимум из одной диаграммы UML.
Для тех, кому лень читать:
Источник: habr.com