Чем могут являться факторы в uml диаграмме

Чем могут являться факторы в uml диаграмме

12 сентября 2023

Скопировано

UML, или Unified Modeling Language, — унифицированный язык моделирования. Это графический язык, который с помощью диаграмм и схем описывает разнообразные процессы и структуры. Это не язык программирования, но чаще всего UML применяют именно в IT — с его помощью можно автоматически генерировать код.

«IT-специалист с нуля» наш лучший курс для старта в IT

Где еще используется UML

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

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

Профессия / 8 месяцев
IT-специалист с нуля

Попробуйте 9 профессий за 2 месяца и выберите подходящую вам

Кто пользуется UML

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

Для чего нужны UML-диаграммы

• Для создания «чертежей» программы, схем, которые показывают, как будет устроено программное обеспечение изнутри, — то есть для проектирования. Это может быть описание связей между компонентами, модулей или сервисов, программных процессов и многого другого. В качестве инструмента проектирования UML может использоваться и вне IT.
• Для визуализации уже имеющейся программной структуры. Ряд инструментов позволяет создать UML на основе существующего кода, в таком случае диаграмма сгенерируется автоматически. Это называется реверс-инжинирингом.
• Для автоматической генерации кода или технической документации по нему, так как UML поддерживает возможность создания продукта на основе диаграмм. Но с этой функцией нужно быть крайне аккуратным: автоматически сгенерированный код позже нуждается в доработке. А вот созданная таким образом документация обычно наглядная и понятная.
• Для внутренней и внешней коммуникации между сотрудниками, заказчиками и другими: картинки и диаграммы UML понятнее людям, чем текстовые описания.

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

Как устроена диаграмма UML

Схема UML — концептуальная: это значит, что она оперирует концепциями и связями между ними. Сама диаграмма состоит из фигур, значков, надписей, линий и контуров.

• Фигуры обычно обозначают ту или иную концепцию: например, объект, класс, группу объектов или что-либо еще. Вариантов фигур в языке множество. Внутри одной фигуры могут находиться другие элементы, главное — чтобы они не пересекали границу.
• Значки тоже обозначают разные сущности, но отличаются от фигур: внутрь них нельзя ничего поместить. Это могут быть более мелкие атомизированные структурные единицы, а могут быть служебные сущности, например для описаний.
• Надписи могут быть обычными, подчеркнутыми, курсивными. Они именуют сущности, показывают, что есть что, и могут использоваться для описаний.
• Линии могут быть прямыми, ломаными, изогнутыми, направленными и ненаправленными, штриховыми и какими-либо еще. Обычно они обозначают связи и зависимости сущностей друг от друга.
• Контуры — это контейнеры, внутри которых помещаются концепции и связи между ними.

Курс для новичков «IT-специалист
с нуля» – разберемся, какая профессия вам подходит, и поможем вам ее освоить

Виды UML-схем

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

Объектные, или структурные — диаграммы, которые описывают статическую структуру системы. Это, например, диаграммы классов в программе. В них показываются сами объекты и классы, связи между ними, зависимости и атрибуты.

Поведенческие — схемы для описания поведения в динамике. Их еще называют динамическими. Это, например, диаграммы, которые описывают процессы.

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

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

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

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

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

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

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

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

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

Недостатки UML

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

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

Как построить UML-схему

Существует два варианта: с помощью любого сервиса для построения диаграмм или благодаря программным модулям.

Сервисы и редакторы. Сервисы дают возможность рисовать диаграммы вручную. Они похожи на графические редакторы, только вместо кистей и ручек в них есть уже готовые компоненты, из которых «собирается» схема. Человек проектирует диаграмму, подписывает элементы, оставляет заметки — такие редакторы предоставляют все необходимое. Некоторые из них могут связываться с сервисами для редактирования документов, хранения данных и других действий. Например, веб-приложение diagrams.net совместимо с облачными сервисами Google и с системами контроля версий Git. Подробнее о Git можно прочесть в нашей статье.

Модули и библиотеки. Модули для IDE и библиотеки для популярных языков программирования позволяют создавать UML с помощью программного кода. Тут тоже есть две версии использования: сгенерировать диаграмму на основе имеющегося кода проекта или запрограммировать ее вручную. Можно описывать на языке программирования элементы и связи между ними, а потом «рисовать» визуализацию с помощью других инструментов. Такие утилиты и библиотеки существуют, например, для Java, JavaScript, PHP и других распространенных языков.

IT-специалист с нуля

Наш лучший курс для старта в IT. За 2 месяца вы пробуете себя в девяти разных профессиях: мобильной и веб-разработке, тестировании, аналитике и даже Data Science — выберите подходящую и сразу освойте ее.

Статьи по теме:

ПОСТАНОВКА ТЕМЫ

Недавно довелось побывать в компании практикующей UML с целью получить работу, однако всё прошло далеко не столь успешно, как хотелось бы – у меня возникли проблемы с созданием моделей UML и описанием сценариев. Всё бы хорошо, если бы все мои знания UML заканчивались прочтением википедии накануне. Но нет, весной 2010 года я проходил обучение в Luxoft, по итогам которого считал, что я в этом разбираюсь и всё хорошо. Однако, когда я за несколько дней начал повторять материал, то пришло осознание, что знания путаются.. Почему такое могло бы быть?

Проблема

На практике я use-cases никогда не использовал и модели не строил (ну, с некоторыми оговорками, но на 97% я в этом предложении не соврал). Понятно, что не имея целый год практики, да и изучив лишь азы, знания быстро забываются. Это было бы не так, если бы я пошел в компанию, которая всё это использует. Но нет, и что же я получаю сейчас: опыт я могу получить в основном в компаниях, которые используют use-cases и модели в своей работе, которые в свою очередь ищут сотрудников с данным опытом, а в итоге выходит замкнутый круг…

Примеры решения

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

Киселев Алексей, Тарханов Павел

Вопросы

1. В компаниях практическое применение UML является ключевым навыком при приеме кандидата (тогда почему этого не указывают в требованиях к кандидату)?
2. Где пройти практику моделирования аналитику, если на его предыдущем месте работы UML не был принят как методика моделирования?
3. Как “выкрутиться” аналитику, если он на предыдущем месте работы дорос до хорошей зарплаты без навыка моделирования UML, а при переходе на новое место его: либо не берут из-за отсутствия этого навыка, либо берут на существенное понижение з/п без установления конкретных сроков, когда эта з/п точно будет повышена по итогам “подтягивания” навыка.
4. В текущей компании не используется UML и процесс хорошо поставлен, так ли важно знать UML или достаточно за неделю понять стандарты и шаблоны, выполняя самые простые задания?
5. Как правильно учить UML и кому его учить необходимо?
6. Что сейчас учат не так по UML?

ИТОГИ И ВЫВОДЫ

1. Знание UML – не главное в деятельности аналитика

Конечно, определять глубину знаний и навык работы соискателя в нотации UML – прерогатива работодателя, но это ли самый главный фактор при прохождении собеседования?
По результатам круглого стола, проведеного 17 августа в офисе компании Luxoft, мы пришли к общему мнению, что это не совсем так…
Следует отметить, что доверять следует тому работодателю, который на собеседовании пытается в первую очередь понять на сколько соискатель знает:

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

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

• выявлять сущности
• определять проблемы и цели
• устанавливать границы системы (исследуемой области)
• выделять операции, комментируя каждый свой шаг

Даже если аналитик не знает UML, задавая правильные вопросы, он уже зарабатывает себе баллы. Главное – установить что именно хочет заказчик (пользователь), что программа (приложение или функция) должна делать в его понимании.
Компании, которые жестко и в первую очередь требуют знание UML, должны вызывать подозрение. Язык UML всегда можно изучить в довольно короткие сроки, а вот системное мышление дано не всем.
Есть ещё такие варианты развития событий, когда незнанием UML пытаются сбить зарплату соискателю. Аналитику снижают зарплату по причине незнания определенных нотаций, диаграмм или тонкостей, без которых, по мнению работодателя, настоящему аналитику не обойтись. Позже может выясниться, что это вообще в данной компании не требуется. Следует заметить, что этот момент лежит на совести работодателя. Захотите ли вы работать в такой компании? Советы аналитику: по возможности выясните до собеседования или во время его, использует ли компания язык UML, в каком объеме, на каких уровнях взаимодействия, приняты ли соглашение о моделировании, есть ли опытные практики, как осуществляется обучение UML.
Если от вас до собеседования требуют решить задачки или пройти тесты (обычно удаленно), в которых используется UML – это нормально. Этот момент носит характер “конкурентного отбора” и “отсева ошибочно забредших”.
Советы аналитику:
а) не надо пугаться таких заданий;
б) пытайтесь выяснить контекст, в котором необходимо начинать создавать диаграммы, на каком уровне абстракции, кто будет принимать результат;
в) узнайте, возможно ли моделировать без использования нотации UML, пользуясь при этом любым другим известным вам визуальным языком;
г) если же вы решились попробовать, вовсе не обязательно “рисовать” без единой ошибки (даже эксперты могут допускать грубые ошибки, поскольку мнений о правильности той или иной модели может быть несколько даже у устоявшейся и опытной проектной команды).
Взаимодействуйте с работодателем, давая понять уровень вашей аналитической подготовки, знаний и опыта работы на проектах, понимания процессов создания ПО и целей создания необходимых артефактов. Учтите: всё зависит от ваших нынешних познаний в UML. Возможно не имеет смысла и начинать решать подобные задачи, откровенно и прямо заявив об этом, сделав акцент на моментах, которые отражают ваш аналитический “багаж”. Как вариант, можете попробовать решить их для собственного развития (если позволяет время), с прицелом на будущее, обсудив результаты на uml2.ru.
Совет работодателю:
а) готовить адекватные тестовые задания, не требующие длительного мыслительного процесса;
б) помечать в тестах уровни сложности для определения уровня аналитика;
в) если тест единый для всех, то следует помечать, что принимается любой ответ в любых возможных нотациях или языках;
г) иметь собственные, правильные со своей точки зрения, ответы на тесты;
д) готовить специалистов HR к ответам на запросы (вопросы) аналитика, настоящий аналитик будет проявлять навык интервьюирования.
Следует отметить, что при собеседовании на должность младшего аналитика вполне может быть поставлена задача – распознать диаграмму, найти очевидную ошибку в ней. Кстати, такие вопросы можно услышать и от HR агенств.
Если уж дело дошло до построения диаграмм и написания сценариев, то помните, что именно вы определяете то, как всё будет работать. На одну большую задачу может быть множество различных решений , а следовательно – правильных наборов диаграмм вариантов использования и сценариев, главное – верная и обоснованная аргументация.
Итог
В заключении можно добавить следующее:

1. При отсутствии навыка моделирования на UML аналитику желательно ознакомиться с основными диаграммами, используемыми в работе (диаграмма вариантов использования, диаграмма деятельности, диаграмма состояний, диаграмма классов), а так же элементами и связями.
2. Аналитику требуется максимально посвятить время изучению процессов сбора требований, их оформления, а также процесса создания ПО.
3. Проводить оценку аналитика на уровень компетентности в знании нотации UML работодатель может, но правильный работодатель не должен делать на этом акцент. На этом моменте аналитику следует сосредоточиться и самому “брать инициативу в руки”, пояснив работодателю, что идентификаторами и результатами деятельности аналитика являются не столько правильно нарисованные диаграммы, сколько навык умения работать с людьми, информацией, анализировать ее, синтезировать и оформлять в любом удобном читателю виде, будь то ГОСТ, Excel, BPMN etc.

2. UML и заказчик

UML, как язык взаимодействия проектной команды, не теряет позиции, и, кроме того, может являться удобным средством коммуникации с заказчиком. Однако, для бизнеса UML – не самый лучший и удобный вариант. Диаграммы в нотации BPMN или ГОСТ являются более подходящими, поскольку они практически не требуют предварительной подготовки читателя для понимания.
Если же заказчик выставляет требования к использованию UML, то сразу следует понимать, что команда разработки должна обладать соответствующими навыками и иметь как минимум одного гуру-эксперта по данному требованию. Простого обучения неподготовленной проектной команды или прослушивания семинаров перед проектом не достаточно.
Иногда может возникнуть обратная ситуация: проектная команда знает и использует UML, но заказчик в этом вопросе некомпетентен. Может потребоваться дополнительное обучение заказчика, но это оправдано и, возможно, достаточно будет представить заказчику описание нотации (соглашение о моделировании).
Здесь же следует отметить, что язык UML больше предназначен для работы внутри проектной команды. Этот язык является прежде всего уровнем “проектных решений”, а не уровнем “выявления проблем и постановки целей”. Документы, с помощью которых мы общаемся на уровне бизнеса (заказчика), должны быть максимально просты, понятны и универсальны для всех, в том числе для топ-менеджмента. Если же заказчик технически подкован, имеет в своем арсенале архитекторов, аналитиков со знанием UML, которые могут его читать, то тогда без нотации UML нам, как исполнителю не обойтись.
Опять же, UML не есть цель – если заказчик беспричинно требует использовать UML, то это должно настораживать. Практика показывает, что многое должно быть описано текстом, иначе работа может просто “лечь в стол”. Почему? Наличие одних лишь диаграмм в чистом виде не достаточно, они обязательно должны дополняться текстом. Любая модель должна состоять из двух частей – диаграммы и текстовой части, ведь диаграмма упрощает понимание визуализируя информацию. Например, вариант использования – это не окончательное проектное решение, оно дает ещё некоторую свободу в реализации, поэтому вся модель вариантов использования может видоизменяться неограниченное количество раз.
Если обратиться к оформлению требований в виде “Система должна…”, то в настоящее время этого уже не достаточно (хотя для заказной разработки по госпроектам только в таком виде требования и оформляются). Необходимо детальнее описывать кто и что делает в виде последовательности шагов сценариев и визуализировать с помощью любых диаграмм.
Формат документов (артефактов) должен быть согласован до начала проектной работы. Одним заказчикам удобнее использовать прототипы, другим – диаграммы и схемы. Для аналитиков они равнозначны, а лучше всего – использовать текстовое описание и диаграммы (UML, ГОСТ, BPMN etc.) дополняя их прототипами.
Совет аналитику: необходимо учитывать, что с одной стороны он взаимодействует на уровне менеджеров, пользователей систем и операторов, а с другой стороны с проектной командой. Очень важно учитывать и отрабатывать навыки коммуникации – это дает знания о том, с кем мы общаемся и его роль в проекте. Общайтесь, и проблемы будут рано или поздно решены.
Примечание: По мнению аудитории по BPMN есть хорошие курсы Анатолия Белойчука.

3. Правильно ли учат аналитиков?

В вопросе выбора обучения следует руководствоваться следующими критериями:

1. Компетентность преподавателя и его опыт
2. Четкая нацеленность курса на конкретный уровень подготовки слушателя: базовый, продвинутый, эксперт
3. Хорошо проработанная теория и большой объем практических занятий
4. Учет занимаемой позиции/должности или роли обучаемого (аналитик, тестировщик, архитектор, дизайнер, разработчик). Например, можно разделить даже на бизнес/системных аналитиков, хотя учитывать, что частично методики перекрываются.
5. Востребованность курсов и студентов после них

Для того, чтобы проверить, на сколько курс соответствует критериям и ожиданиям следует просмотреть его анонс, прочитать о преподавателе, посмотреть состав курса. Очень важно убедиться в наличии в процессе обучения практических заданий (иногда они решаются в смежном курсе). На российском рынке на данный момент, в основном, представлены курсы для начинающих!
При обучении UML следует понимать, что мы изучаем инструмент, а не процессы создания ПО, или, например, “Методы интервьюирования заказчика” – это иной курс!
Рекомендуется проходить курсы по UML после изучения наиболее важных предметов деятельности аналитика. Без практического использования знания быстро забываются, а без предварительной базовой подготовки так и вообще пустая трата времени и существенные финансовые потери. Здесь можно сказать, что изучение UML, как изучение иностранного языка – требует постоянной практики.
На сегодняшний день на российском рынке не существует ни одного семинара и курса с методикой преподавания UML, после которой можно с уверенностью и гарантией утверждать: “Ученик полностью готов правильно применять нотацию UML в проектной деятельности”. Как строить эту методику? Вопрос на круглом столе остался открытым.

4. Взаимодействие с разработчиками

Основная проблема, озвученная одним из присутствующих разработчиков – аналитик считает, что ему незачем тратить время на создание и оформление UML-диаграмм, если достаточно описать это текстом. Тем не менее, нам, аналитикам , надо работать так, чтобы разработчик всё понял однозначно и, желательно, в кратчайшие сроки (это, кстати, политика одного крупного системного интегратора в США, где разработчики могут предъявлять требования к постановкам на разработку).
Гораздо лучше, если постановка передается в работу после того, как разработчики и тестировщики ее посмотрели (проработали совместно), так они могут найти дополнительные альтернативные сценарии, либо иные проблемы. Это уже вопрос тестирования требований и проектного управления, он выходит за рамки круглого стола.
Совет аналитику: Ищите среди проектной команды коллег, знающих UML или проявляющих к нему интерес, договаривайтесь внутри команды о языке взаимодействия (соглашениях о моделировании) и держите в курсе вашего интереса менеджера проекта. За внедрение UML в компании ответственно руководство, но, инициатива может идти от аналитиков, разработчиков и тестировщиков.

5. Вместо заключения

“У страха глаза велики”
Народная мудрость

Общий вывод, который мы сделали по итогам круглого стола, такой: UML – это не панацея от всех бед, встающих на тернистом пути аналитика при работе с заказчиком и информацией, тем более не обязательный и ключевой инструмент, требующийся в работе. Знание UML является хорошим довеском к наиболее важным и ключевым навыкам аналитика (преимущественно “системного аналитика”), таким как: коммуникации, анализ, синтез, работа с информацией и документирование. Язык UML всегда можно изучить в довольно короткие сроки, а вот навыки системного мышления даются с трудом и далеко не всем.

Большое спасибо Александру Белину и Александру Байкину за активное участие в КС и множество полезной информации.

UML для разработчиков

Интернет полон статей про UML, вы найдете сотни примеров для каждого вида диаграмм, и без проблем создадите свои, нотация не сложная. Но так ли уж необходимо тратить на это время? Наш богатый опыт говорит «Да». Если у вас в команде более 2 человек и проект от 3 месяцев, то уже имеет смысл отрисовать 2-3 вида диаграмм. В одной нашей команде более 30 человек, проект длительностью более 3 лет, и мы используем. 2-3 вида диаграмм.

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

В чем будем рисовать?

Если ваша цель «быстро и красиво» (например, для презентации или для этой статьи), то Visio подходит более чем: его редактор удобен и прощает любые отступления от нотации.

Если же вы занимаетесь проектированием, то потребуется полноценная система с поддержкой связей между диаграммами. Мы используем продукт Enterprise Architect, дешево и сердито.
Сравнение систем проектирования и рассказ о том, как ими правильно пользоваться — тема для отдельной статьи.

Техническое задание

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

Самая простая диаграмма — Use Case (Варианты использования):

На диаграмме указаны виды пользователей и перечислены функции или группы функций, которые с ними связаны. Синим цветом выделен элемент, которого в UML нет, но его часто не хватает: Requirement — Требование (из нотации Archimate), уточнение функций.

Вы спросите — и какой в этом смысл? Ведь перечень функций можно указать просто текстом, одним компактным списком! И будете правы, но есть нюансы.

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

Почему для связи элементов мы использовали линии, а не стрелки? Потому что никто не помнит, как выглядят стрелки «Обобщение» и «Расширение», и что они вообще такое. Чем проще вы нарисуете, тем больше людей поймет диаграмму без вашего участия.

Второй вид диаграмм, который вы можете встретить в техническом задании, это Activity diagram:

Здесь для разработчика все очевидно, кроме одного: почему AI делает вызовы Студента? Не делает. Эту диаграмму рисуют аналитики, а не программисты, они не знают где клиент, а где сервер, и их не интересуют потоки данных. На Activity diagram вы видите последовательность действий и не более того. Как же из этого сделать код? Переходим к этапу проектирования.

Проектирование архитектуры

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

• Подсистема бронирования уроков
• Подсистема Web-тренировок
• Биллинг
• Подсистема управления записями голосов

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

Для каждой подсистемы потребуется Архитектурная схема, как ее правильно нарисовать? В UML для этого нет подходящих диаграмм, давайте посмотрим на Archimate:

Даже без знания нотации схема, в целом, читаема. Помните, что 90% участников вашей команды не знают ни UML, ни тем более Archimate, и никогда не выучат эти нотации, поэтому делайте упор на надписи. Тем не менее, пара слов о кубиках и стрелочках:

Полную спецификацию Archimate вы найдете без труда.

Цвет — на ваш вкус, нотация никак их не регламентирует. Раскрасьте одним цветом текущую подсистему, вторым — смежные подсистемы, третьим — внешние системы, это сильно повышает читаемость схемы.

На схеме используется всего два вида стрелок: Flow (Поток) и Access (Вызов, Доступ). Поток показывает направление передачи данных, а Вызов — кто к кому обращается. Следует правильно понимать стрелку Поток:

На схеме не отображен поток от мобильного приложения к серверу, хотя на самом деле он есть (первым идет поток «Запрос данных»). Делается это для того, чтобы схема проще читалась: показываем только самое важное. То, что есть еще и исходный Запрос данных и так очевидно из кубика с надписью API.

Детализация

Последние две диаграммы, которые очень полезны (внимательный читатель конечно заметил, что всего видов диаграмм уже не 2-3): Sequence diagram (Диаграмма последовательности) и Class Diagram (Диаграмма классов, но вовсе не для классов).

Иногда взаимодействие клиента и сервера многоступенчатое, с использованием третьих ресурсов. Например, авторизация с Oauth2: текстовое описание этого процесса весьма затруднительно для понимания. Здесь нам поможет Sequence diagram:

Данная реализация Oauth2 не эталонная, вариантов может быть много. Самое главное, что нужно понимать на схеме — на этой диаграмме нет потоков данных, только Вызовы и Ответы на вызовы. Хотя это не помешало нам указать потоки текстом на стрелках.

Когда вы углубитесь в изучение Sequence diagram вы обнаружите, что она позволяет отобразить циклы и ветвления, но не злоупотребляйте ими: не нужно на одной диаграмме рисовать ветки «Если пользователь выбрал локальную авторизацию, то» и «Если выбрал авторизацию FB, то», вместо этого нарисуйте две схемы под каждый вариант. Условия, особенно вложенные, на Sequence diagram очень сильно снижают читаемость схемы.

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

Но практическое применение у Class Diagram все же осталось — проектирование баз данных:

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

Не пытайтесь рисовать это в Visio, Enterprise Architect или аналогах. Для проектирования баз данных есть много специализированных инструментов, которые заточены под конкретные СУБД, пользуйтесь ими.

На этом все. Из всех диаграмм в UML и Archimate на практике более чем достаточно перечисленных. Сколько диаграмм каждого вида нужно для проекта? Рисовать ли их под каждый процесс и подсистему? Главное правило — диаграмма сопровождает текстовое описание, она нужна только там, где текста недостаточно, т.е. там, где команда вас не понимает.

Спасибо за внимание, с вами была компания «Программный продукт».

• Блог компании Программный Продукт
• Проектирование и рефакторинг
• UML Design
• Управление проектами

Основы UML. Кому и зачем нужен UML

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

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

Время на чтение статьи: 17 минут
Не любите читать? Посмотрите видео.
Оглавление

• Определение
• История возникновения UML
• Классификация UML диаграмм

• UML для Заказчика
• UML для Аналитика
• UML для Архитектора
• UML для Разработчика
• UML c позиции Тестировщика
• UML для Технического писателя

• Какие задачи на UML встречаются на собеседованиях?
• Правда ли, что UML используют только в больших компаниях?
• Обязательно ли знать программирование для работы с UML?
• На каких практических кейсах можно потренироваться в UML?
• Можно ли моделировать сложную логику UML в MS Visio?
• Как быстро освоить Enterprise Architect?
• Зачем нужна диаграмма классов, если есть ER-диаграмма?
• Как связаны UML и BPMN?

Что такое UML

Определение

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

Давайте подробнее разберём аббревиатуру UML:

• U — Unified (Унифицированный). Большой набор элементов, входящих в нотацию, позволяет покрывать много задач на этапе анализа и проектирования. Ещё одна версия происхождения этого слова кроется в том, что нотация объединила в себе несколько разнородных нотаций, существовавших ранее.
• M — Modeling (Моделирование). Создание диаграмм заключается в разработке моделей, содержащих наполненные информацией и связанные между собой графические объекты.
• L — Language (Язык). UML является искусственным языком и обладает свойствами языка: имеет словарь (графические символы), семантику (смысловые значения элементов) и синтаксис (правила построения конструкций). В нотацию также заложена возможность генерации кода из графической модели и генерация моделей из кода.

История возникновения UML

UML является далеко не первой нотацией моделирования. Графически описывать системы при проектировании и разработке стали давно. В какой-то момент появилась необходимость в том, чтобы использовать при моделировании единые правила, понятные всем.

В основу нотации легли наработки многих специалистов в области программной инженерии, но наиболее весомый вклад внесли Грейди Буч (Grady Booch), Айвар Джейкобсон (Ivar Jacobson) и Джеймс Рамбо (James Rumbaugh). UML вобрала в себя особенности их нотаций моделирования — Booch, OOSE (Object Oriented Software Engineering) и OMT (Object Modeling Technique) соответственно.

Рис. 1 — История возникновения нотации UML

Язык постоянно развивается, появляются новые элементы для моделирования более сложных систем. Актуальная сейчас версия нотации — UML 2.5.1; новости и рекомендации можно найти на официальном сайте UML.org.

Классификация UML диаграмм

Нотация известна тем, что в неё входит много различных видов диаграмм:

Рис. 2 — Классификация диаграмм нотации UML
Структурные диаграммы UML. Описывают систему статически
Диаграмма;Описание

Диаграмма классов (Class Diagram);Описывает систему в виде набора классов со свойствами, доступными методами и взаимосвязями между классами. Диаграмма объектов (Object Diagram);Является экземпляром диаграммы классов и показывает конкретные значения свойств классов. Диаграмма пакетов (Package Diagram);Описывает взаимосвязи пакетов. Пакет — группа классов, объединенных для упрощения сложной диаграммы классов. Диаграмма компонент (Component Diagram);Описывает архитектуру компонентов (сервисы, интерфейсы, приложения и т.д.) и зависимости между ними. Диаграмма развертывания (Deployment Diagram);Описывает архитектуру системы с точки зрения ее развертывания на физическом уровне. Диаграмма профилей (Profile Diagram);Описывает пользовательские стереотипы и ограничения, применяемые к моделям. Диаграмма композитной структуры (Composite Structure Diagram);Описывает внутреннюю структуру классов и взаимодействие элементов класса между собой.

Диаграммы поведения UML. Описывают систему динамически

Диаграмма;Описание

Диаграмма прецедентов (Use Case Diagram). Употребляется также термин «Диаграмма вариантов использования»;Описывает набор функциональности (прецедент), доступной акторам (внешним для системы сущностям, например, пользователям). Диаграмма деятельности (Activity Diagram);Описывает рабочий процесс внутри каждого прецедента. Диаграмма состояний (State Machine Diagram);Описывает состояния, в которых может находиться каждый объект, и правила перехода из одного состояния в другое. Диаграммы взаимодействия; Диаграмма последовательности (Sequence Diagram);Описывает логику взаимодействия и обмена данными между объектами в рамках прецедента в хронологическом порядке. Диаграмма коммуникации (Communication Diagram);Описывает логику взаимодействия и обмена данными между объектами в рамках прецедента. Схожа с sequence diagram, но без раскрытия хронологического порядка. Диаграмма синхронизации (Timing Diagram);Описывает как объекты ведут себя на временной шкале без отображения взаимосвязей между объектами. Диаграмма обзора взаимодействия (Interaction Overview Diagram);Описывает процесс взаимодействия объектов. Похожа на activity diagram, но более высокоуровневую, где каждый узел — другая диаграмма взаимодействия.

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

Применение UML к разным задачам

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

Задача;Диаграммы

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

• Class Diagram
• Activity Diagram
• Sequence Diagram
• Use Case Diagram