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

В программировании нам тоже нужны такие «чертежи». Код, конечно, всё описывает — но чтобы разобраться в архитектуре проекта из 200 файлов, нужно потратить часы. А что если можно показать ту же идею одной схемой?

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

А можно нарисовать одну схему, и всё станет понятно за 10 секунд. Вот в чём сила UML — он превращает сложное в наглядное.

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

Давайте посмотрим на конкретном примере. Вот три класса на C#:

public interface ISpell
{
    string Name { get; }
    void Cast(string casterName);
}

public class Fireball : ISpell
{
    public string Name => "Fireball";
    public void Cast(string casterName)
        => Console.WriteLine($"{casterName} запускает огненный шар!");
}

public class Mage
{
    public string Name { get; }
    private ISpell _spell;

    public Mage(string name, ISpell spell)
    {
        Name = name;
        _spell = spell;
    }

    public void Attack() => _spell.Cast(Name);
}

Три класса, интерфейс, зависимость через абстракцию. Чтобы разобраться — нужно прочитать ~20 строк кода. А вот та же структура на UML:

Одна схема — и сразу видно: Mage зависит от ISpell (абстракция), а Fireball реализует этот интерфейс. Никакого чтения кода — всё понятно за пару секунд.

UML используют для нескольких целей:

Проектирование до написания кода. Вы рисуете классы, их связи, поведение — и видите архитектуру ещё до первой строчки. Это экономит время: переделывать схему дешевле, чем переписывать код.

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

Общение в команде. Архитектор рисует схему на доске, и вся команда понимает, что нужно сделать. Без UML пришлось бы объяснять словами — долго, неточно, каждый поймёт по-своему. UML — не один тип диаграмм, а целое семейство. В стандарте их 14 штук (да, четырнадцать!), но на практике большинство разработчиков используют 4–5 основных. Все диаграммы делятся на две большие группы:

Структурные диаграммы — показывают, из чего состоит система: какие есть классы, компоненты, пакеты и как они связаны. Это статическая картинка — как фотография. Самая популярная — диаграмма классов (Class Diagram).

Поведенческие диаграммы — показывают, что происходит во времени: кто кого вызывает, в каком порядке, при каких условиях. Это как видео. Самые популярные — диаграмма последовательностей (Sequence Diagram) и диаграмма вариантов использования (Use Case Diagram).

Вы наверняка слышали мнение, что UML — это «бюрократия» и «трата времени». Разберёмся, когда это правда, а когда — нет.

UML полезен, когда:

— Вы проектируете сложную систему с множеством классов и зависимостей.

— Нужно объяснить архитектуру новому члену команды.

— Команда обсуждает дизайн и нужна общая визуальная основа.

— Вы готовитесь к собеседованию на позицию, где спрашивают системный дизайн.

UML лишний, когда:

— Вы пишете маленький скрипт на 50 строк.

— Диаграмма устаревает на следующий день и никто её не обновляет.

— Команда тратит больше времени на рисование схем, чем на написание кода.

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

В agile-командах часто рисуют «лёгкий UML» — не по всем правилам стандарта, а ровно столько, сколько нужно для понимания. Белая доска, маркер, три прямоугольника и пара стрелок — и вся команда на одной волне. Это тоже UML, просто неформальный. Коротко о том, что нас ждёт дальше. В этом курсе мы пройдём UML от простого к сложному:

Сначала — история и версии UML (откуда он взялся и почему «унифицированный»). Затем — типы диаграмм подробнее. Потом — инструменты (draw.io, PlantUML, Mermaid — чем рисовать). И наконец — научимся читать чужие диаграммы, прежде чем начнём рисовать свои.

После вводного блока мы перейдём к конкретным диаграммам: Use Case, классы, последовательности, состояния, активности, компоненты, развёртывание. Каждая — с примерами, практикой и реальными сценариями.

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