Карьера в IT. Системный аналитик, часть 3, диаграммы. UML⁠⁠

Всем привет.

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

Зачастую у многих возникает вопрос - а зачем вообще рисовать любые диаграммы и схемы? Мы все такие замечательные, уже научились писать требования, оформлять разными способами (даже красивыми) - в общем-то, по этим требованиям же и так всё понятно?

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

Это я подвожу к тому, что если у тебя есть свободное время на создание схемы (а это бывает не так часто), то лучше ее сделать. А возможно и в целом начать аналитику именно с нее. Это поможет структурировать твои собственные мысли, увидеть возможные неточности или не проработанные моменты в том или ином процессе.

UML

UML – унифицированный язык моделирования (Unified Modeling Language) – это система обозначений, которую можно применять для объектно-ориентированного анализа и проектирования. Его можно использовать для визуализации, спецификации, конструирования и документирования систем.

UML использует в основном графические обозначения для выражения дизайна проектов. Использование UML помогает проектным группам лучше взаимодействовать между собой и легче вникать в проекты.

Основные цели дизайна UML:

• Предоставить пользователям готовый, выразительный язык визуального моделирования, чтобы они могли разрабатывать и обмениваться осмысленными моделями;

• Быть независимым от конкретных языков программирования и процессов разработки (важно);

• Обеспечить формальную основу для понимания языка моделирования;

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

Преимущества и недостатки проектирования диаграмм:

Начнем с недостатков:

• Дополнительная трата времени, которого может и не быть;

• Необходимость знать и понимать различные нотации.

Преимущества:

• Возможность посмотреть на задачу с разных точек зрения;

• Другим членам команды (включая заказчиков) легче понять суть задачи и способ ее реализации;

• Диаграммы сравнительно просты для чтения после достаточно быстрого ознакомления с их синтаксисом.

В UML диаграммы подразделяют на два типа — это структурные диаграммы и диаграммы поведения.

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

• Диаграмма составной структуры

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

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

• Диаграмма профилей

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

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

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

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

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

• Диаграмма прецедентов

• Диаграмма состояний

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

• Диаграмма коммуникаций

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

• Временная диаграмма

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

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

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

Три наиболее важных типа отношений в диаграммах классов (на самом деле их больше), это:

• Ассоциация - представляет отношения между экземплярами типов. Например, человек работает на компанию, у компании есть несколько  офисов;

• Зависимость — это форма отношения использования, при которой изменение в одном классе - влечёт за собой изменение другого, причём обратное не обязательно.

• Агрегация - это ассоциация типа «целое-часть». При этом обе части могут жить отдельно друг от друга (машина - колесо).

• Композиция – это такая агрегация, где объекты-части не могут существовать сами по себе (дом - комната).

Пример:

Стоит еще рассказать про такую вещь как "Кратность". По сути между объектами может быть всего 3 типа кратности, которые уже могут варьироваться:

• 1 к 1. Это значит, что ровно одному объекту соответствует ровно один объект. Например - у одного человека может быть только один паспорт (не берем загранник);

• 1 ко многим. Одному объекту может соответствовать множество объектов (множество это может быть и 0). Например - один автор написал много книг;

• Многие ко многим. Множеству объектов может соответствовать множество других объектов. Например - много поставщиков поставляют много товаров (в том числе пересекающихся).

При этом могут быть частные варианты, такие как, как 1 : 0..* (1 объекту соответствует множество объектов или ни одного. Например, у одного покупателя может быть множество заказов, но их может и не быть совсем). Или 1 : 3..*, т.е. одному объекту соответствует минимум три других и в целом любые возможные комбинации.

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

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

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

Актер - если упростить, то это какой-то конкретный пользователь или роль, или другая система, подсистема или класс.

Другой участник данный диаграммы - прецедент. Это описание отдельного аспекта поведения системы с точки зрения пользователя (да, это те самые UC, которые рассматривали в прошлой части).

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

Пример диаграммы:

В языке UML несколько стандартизированных видов отношений между актерами и вариантами использования:

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

Отношения обобщения - показывает, что определенный актёр или вариант использования может быть обобщён до другого актёра или варианта использования. Как на примере выше - UC "открытие счета ФЛ" и "открытие счета ФЛ" обобщены в UC "Открыть счет".

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

Например, при предоставлении кредита в банке всегда происходит проверка платежеспособности клиента.

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

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

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

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

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

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

Если рассматривать схему из примера, то это работает примерно так:

Стартовый статус нашей системы = "Бездействие". Дальше, если срабатывает триггер (допустим, получаем сообщение от датчика температуры, что она превысила установленную норму) - то система начинает переходить к общему статусу "Охлаждение". Он в свою очередь состоит из нескольких процессов - запуск компрессора, готовность и работа вентилятора.

Система находится в этом состоянии, до тех пор пока снова не срабатывает определенный триггер, например - получение сигнала от датчика температуры о том, что она вернулась в норму. В этом случае вентиляторы останавливаются и система снова переходит в статус = "Бездействие".

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

Послесловие.

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

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

P.S. Про UML это еще не всё, но пост получается очень большим, поэтому разобью на две части и добью остаток про UML в следующей. Заодно там же начну рассказывать про BPMN.

P.P.S: Завтра (25.02.2023 в 12.00 московского времени) у меня в телеграмме пройдет эфир где я буду отвечать на разные вопросы про карьеру/профессию/перспективы/развитие и т.д. В общем на все вопросы, которые мне будут задавать участники эфира.

Ничего продавать не буду, поэтому если хотите поболтать\послушать или даже есть какие-то вопросы на указанные темы - приходите, буду рад всем. Ссылка на телеграмм в моем профиле.