UML за 10 минут. Sequence диаграмма последовательности. Системный анализ

Бизнес анализ BPMN требования - Максим Филиппов
27 Aug 202310:18

Summary

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

Takeaways

  • 📚 В уроке рассматривается тема UML-диаграмм последовательности, которые часто используются для описания взаимодействия компонентов в распределенных системах.
  • 🛠 Основные элементы диаграммы последовательности включают компоненты, взаимодействия, операции и сообщения между ними.
  • 🎨 Компоненты на диаграмме изображаются как прямоугольники, без строгой нотации, но с указанием их роли и названия.
  • 🔍 Для назначения компонентов рекомендуется указать их тип в одной строке и конкретное название в другой.
  • 💬 Сообщения в диаграмме могут быть исходящими (черная стрелка) или ответными (пунктирная линия), и они показывают взаимодействие между компонентами.
  • 🛑 Операции представляют собой действия, которые выполняются компонентами, и отмечаются особым образом на диаграмме.
  • 🔄 Примеры процесса могут включать в себя валидацию данных, проверку прав доступа пользователя, обработку запросов и возврат результатов.
  • 🔍 Для удобства понимания и дальнейшего описания алгоритма рекомендуется нумеровать сообщения и действия на диаграмме.
  • 📝 Важно, чтобы диаграмма была понятна для разработчиков и отражала процесс взаимодействия, не бойтесь добавлять детали для лучшего понимания.
  • 📐 Используются различные инструменты для создания диаграмм, включая бесплатные онлайн-решения и более сложные Enterprise-решения с автоматизацией рутинных задач.
  • ⚙️ Важно выделять альтернативные и опциональные пути в диаграмме, чтобы показать различные варианты развития процесса.

Q & A

  • Что такое диаграмма последовательности UML?

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

  • Какие элементы являются основными в диаграмме последовательности?

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

  • Какие символы используются для представления компонентов в диаграмме последовательности?

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

  • Как следует обозначать компоненты в диаграмме последовательности?

    -Компоненты должны быть четко обозначены, указывая их название и, при необходимости, тип компонента, например, 'Frontend' или 'Backend'.

  • Что такое исходящее и ответное сообщение в контексте диаграммы последовательности?

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

  • Какие инструменты можно использовать для создания диаграмм последовательности?

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

  • Чем отличается Enterprise Architect от других инструментов для создания диаграмм?

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

  • Что значит термин 'альтернативное' в контексте диаграмм последовательности?

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

  • Какова цель использования 'опциональных' элементов в диаграмме последовательности?

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

  • Почему важно нумеровать сообщения в диаграмме последовательности?

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

  • Какие рекомендации дает автор по поводу стиля и содержания диаграмм последовательности?

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

Outlines

00:00

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

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

05:02

📝 Советы по созданию и оформлению UML-диаграмм последовательности

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

10:02

🔍 Подведение итогов и рекомендации по UML-диаграммам последовательности

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

Mindmap

Keywords

💡UML диаграммы

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

💡Последовательность

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

💡Компоненты

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

💡Взаимодействие

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

💡Операции

Операции в контексте UML диаграмм - это действия, выполняемые компонентами системы. В видео операции представлены как действия, такие как валидация данных или создание заявки.

💡Сообщения

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

💡Альтернативные пути

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

💡Опциональные элементы

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

💡Цикл

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

💡Нумерация сообщений

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

💡Технический ключ

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

Highlights

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

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

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

Черные стрелки обозначают исходящие сообщения, а пунктирные — ответные сообщения.

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

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

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

Использование номерации сообщений и действий в диаграмме упрощает написание текстового описания алгоритма взаимодействия.

Enterprise Architect является удобным инструментом для создания UML-диаграмм, автоматизируя рутинные задачи.

Для улучшения понимания диаграммы рекомендуется добавлять ключевые параметры и комментарии к сообщениям.

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

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

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

Альтернативные блоки обозначаются префиксом 'Alt', опциональные — условием их выполнения.

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

Transcripts

play00:00

друзья Всем привет данном уроке мы

play00:02

поговорим про uml диаграммы

play00:03

последовательности они у нас очень часто

play00:05

практически всегда используется при

play00:08

описании взаимодействия компонентов

play00:10

распределенной системы это то как раз

play00:12

чем мы занимаемся при проектировании в

play00:15

системном анализе Давайте поэтому сразу

play00:17

переходить к делу

play00:19

и рассмотрим основные элементы диаграммы

play00:22

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

play00:24

последовательности ее название заявка

play00:26

создать новую и рассматриваем допустим

play00:29

успешный вариант тут у нас есть Легенда

play00:31

и тут основное содержимое нашей

play00:34

диаграммы что мы видим У нас есть

play00:36

компоненты У нас есть взаимодействие

play00:38

какие-то операции вот от начала до конца

play00:40

это все изображено вот об этом есть

play00:42

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

play00:44

последовательности обработки каких-то

play00:46

запросов Итак прежде всего когда мы

play00:50

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

play00:51

последовательность мы должны обозначить

play00:52

компонент

play00:54

нет какой-то строгой нотации Но как

play00:57

правило они изображают прямоугольниками

play00:59

основные части основные компоненты

play01:01

систем

play01:02

человек или там пользователь какой-то

play01:05

абстрактный или роль выражается рисуется

play01:09

человечком база данных можно рисовать

play01:11

как-то вот нет какой-то строгой нотации

play01:14

Ну примерно так принято можете

play01:16

пользоваться Именно таким подходом

play01:21

добавили компоненты которые будут между

play01:23

собой взаимодействовать мы должны их

play01:26

назвать тут тоже нет какой-то строго

play01:29

нотации но Я рекомендую то есть вот

play01:30

допустим у нас есть фронтен значит и

play01:32

Back and и база данных соответственно

play01:34

второй строкой мы подчеркнем как бы суть

play01:36

тип этого компонента

play01:39

а первой строкой мы назовем

play01:42

точнее ставим название конкретное

play01:44

название техническое конкретного

play01:46

компонента допустим у нас май называется

play01:49

наш контент весь наш сервис My fservice

play01:53

называется соответственно мы так и

play01:55

название и дадим соответственно нам все

play01:58

понятно тут у нас есть админ мы

play02:00

подчеркнули что это роль тут написали

play02:01

что

play02:03

опять же чувствуете себя спокойно в этих

play02:05

свободно в этих названиях Главное чтобы

play02:08

передавать поднимать что у нас еще есть

play02:11

у нас есть основные элементы

play02:16

черная заполненная стрелочкой это

play02:18

исходящая сообщение ответное обратное

play02:21

сообщение это пунктирное сообщение

play02:22

Давайте посмотрим вот из Киль запрос

play02:25

данные или вот обратный ответное

play02:27

сообщение все у нас есть произведение

play02:29

операции это когда мы не Отправляем

play02:32

сообщение в компонент Ну вот таким

play02:34

образом помечаем что мы что-то делаем

play02:36

допустим тут на фронтенде производится

play02:38

валидация тех полей которые вел админ И

play02:41

после этого нажал создать заявку линия

play02:44

жизни это просто пометка такая

play02:47

Мы отмечаем ту линию на которой у нас

play02:52

будут

play02:53

фиксироваться действия для конкретного

play02:55

компонента В общем просто к

play02:58

геометрическая штука активация объекта

play03:00

это знаете что объект активен если у нас

play03:03

Вот есть такой прямоугольничек то есть

play03:05

активен он либо ожидает ответ либо

play03:08

производит какие-то действия Когда у нас

play03:11

такого нет то есть у нас просто есть

play03:12

линия жизни а потом раз у нас опять

play03:14

активировался объект опять Вот такая

play03:15

штучка появилась прямоугольничек значит

play03:17

он у нас начал быть активен А до этого

play03:20

он Отработал и всё о себе

play03:24

больше не добавишь Давайте посмотрим

play03:27

у нас нажимается сдать заявку проводит

play03:31

валидацию это летит по запросам по

play03:33

такому-то

play03:35

адресу соответственно передается вот

play03:37

такой тип данных

play03:39

прокси проверяет право пользователя и

play03:43

сейчас опять же Это пример не

play03:44

обязательно что это всегда вот так вот

play03:45

должно быть прокси может быть не быть

play03:47

могут быть другие компоненты просто

play03:48

пример тут тоже самое пересылается этот

play03:50

запрос Back проводит валидацию проводит

play03:53

преобразование соответствии с алгоритмом

play03:54

делают узкий или запрос база данных

play03:57

отдает данные но тут можно еще сделать

play03:59

производит преобразование

play04:02

данных от BD ответное сообщение и

play04:06

соответственно формате json это

play04:07

возвращает То есть тут могут быть файл

play04:10

какие-то данные тут уже конкретно же сон

play04:13

без какого-либо файла возвращается все

play04:15

вернулся на фронт отобразилось сообщение

play04:17

и отобразилась админ вот собственно

play04:19

полный цикл такой самый частый Когда у

play04:22

нас есть база данных

play04:24

Итак где это все можно

play04:28

делать можно делать это либо другого

play04:30

бесплатный онлайн инструменты чаще всего

play04:32

это делают именно и вот в этом

play04:35

инструменте есть Очень удобная штука но

play04:37

намного весит это Enterprise архитект я

play04:39

использую на работе она вот уже

play04:41

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

play04:43

отличие рисовала как-то рисовать можно

play04:45

что угодно где угодно просто Enterprise

play04:47

архитектор

play04:49

автоматизирует много такой рутины То

play04:51

есть если я что-то подвину то у меня все

play04:53

внизу подвинется а вот нужно там

play04:56

дополнительные действия проводить

play04:57

поэтому

play04:58

более удобный

play05:01

касательно того Давайте поговорим что

play05:04

нужно писать И что не нужно писать Вот

play05:07

именно в самих на самих стрелочках

play05:09

Прежде всего я вам хочу сказать чтобы вы

play05:12

жестко не ориентировались на какие-то

play05:14

рекомендации еще чего-то Самое главное

play05:16

ваша схема должна быть понятна для того

play05:19

кто ее будет смотреть это разработчики и

play05:21

соответственно вы отображаете процесс

play05:23

взаимодействия вот и не бойтесь написать

play05:25

чего-то как вам покажется может быть

play05:28

избыточного побольше

play05:30

сделать Вашу программу информативной Не

play05:32

бойтесь не нужна там сухость еще что-то

play05:34

лучше будет чуть подробнее на мой взгляд

play05:37

чем будет чуть не понятнее для всех

play05:40

остальных соответственно как

play05:43

Когда у нас производится какие-то

play05:45

операции то вы можете прям прописать

play05:48

тезисном формате что у нас проводится

play05:50

чтобы это было такое общее понимание и

play05:52

не нужно было лезть в текстовое описание

play05:54

процесса чтобы там понять какую-то общую

play05:57

суть вот у нас производится валидация мы

play05:58

так и делать пишем проводит валидацию

play06:01

сама форма действия или сообщения вот

play06:04

опять же что делает и с чем делает

play06:07

нажимает что создать заявку Окей

play06:09

касательно сообщений тут у нас разные

play06:12

могут быть протоколы еще что-то тут у

play06:15

нас допустим опять же архитектуры

play06:16

поверхности тебе протокол для понимания

play06:19

для закрепления мы пишем метод и адрес

play06:22

по которому Обращаемся и Мы также для

play06:26

удобства можно отразить

play06:28

тип

play06:29

данных которых мы отправляем тут еще

play06:33

можно перечислять в том числе какие-то

play06:35

ключевые

play06:37

параметры то есть написать скобках в том

play06:40

числе и какие-то параметры то есть опять

play06:42

же чувствуете себя свободно если вам

play06:44

нужно передать какой-то смысл суть то

play06:47

это и делать больше наверное особо Тут

play06:51

ничего не скажешь Давайте посмотрим

play06:52

некоторые моменты

play06:53

Когда у нас все хорошо все прекрасно мы

play06:56

очень легко это рисуется Но есть другие

play06:58

моменты когда у нас нужно выделить

play07:00

какие-то либо альтернативные либо

play07:02

опциональные куски нашей диаграммы

play07:05

альтернативные Но это означает что у нас

play07:07

допустим мы на предыдущем шаге затея

play07:10

какую-то проверку и у нас либо проверка

play07:14

прошла успешно и какой-то набор

play07:15

сообщений А если проверка прошла

play07:17

неуспешно И там что-то отклонено то у

play07:20

нас соответственно Вообще другой

play07:21

параметр сообщений с другими

play07:23

компонентами поэтому это добавляется вот

play07:25

такой прямоугольник него Здесь пишется

play07:27

Alt префикс то есть альтернатива и мы

play07:30

пишем для чего это альтернатива если

play07:32

отклонено и соответственно вот такие-то

play07:34

параметры и то же самое мы напишем Alt

play07:37

если там принят да если одобрят то же

play07:40

самое опционально опционально Это когда

play07:42

не обязательно То есть у нас не проверка

play07:44

Когда у нас допустим какой-то признак

play07:46

есть он срабатывает то мы опционально

play07:49

можем это проверить по определенному

play07:51

алгоритму соответственно мы это тоже

play07:52

отмечаем что что-то не таких штук бывает

play07:55

много но я советую не усложнять

play07:58

максимально вот что на практике по моему

play08:00

опыту используется эта альтернатива

play08:02

опционально вот я привел справа еще

play08:04

разные штуки но еще наверное лук когда у

play08:06

нас что-то в цикле происходит до чего-то

play08:08

Вот это тоже можно пометить Да что у нас

play08:11

вот такой цикл происходит запросов

play08:13

запросов запросов там по всем записям

play08:15

ответа И это тоже удобно пометить но

play08:18

остальное привел но часто это не

play08:20

используется Давайте посмотрим что у нас

play08:22

еще есть что я хотел сказать Прежде

play08:24

всего я очень рекомендую это не

play08:27

обязательно правилам назад но я очень

play08:29

рекомендую нумеровать ваши сообщения

play08:30

потому что вы дальше будете в

play08:32

обязательном порядке писать текстовое

play08:34

описание алгоритма взаимодействия и

play08:36

очень удобно потом ссылаться на шаги это

play08:39

вам очень поможет и поможет тем кто это

play08:41

будет читать и сравнивать схемой и так

play08:43

далее поэтому закрепим то что мы шаги

play08:46

все сообщения все действия

play08:49

это все делается автоматом опять же Это

play08:52

очень удобно

play08:53

Так

play08:54

ну вот я привел пример еще идентификации

play08:57

авторизации обработка данных опять же

play08:59

говорю чувствуете себя свободно Если

play09:01

хотите побольше написать для понимания

play09:03

пишите тут вы не обязаны писать с другой

play09:05

стороны все наиболее детально какие-то

play09:08

основные моменты основные операции можно

play09:10

вот обобщать и прописывать

play09:13

Так что еще у нас есть еще одна картинка

play09:19

тут я хотел Подсказать вам что опять же

play09:22

мы можем допустим у нас есть возврат

play09:24

ответа и мы в скобках Передаем какие-то

play09:27

ключевые параметры которые мы хотим

play09:29

подсветить чтобы при этом ответьте они в

play09:31

том числе передаются или передаются

play09:32

только они здесь я хотел пометить что

play09:35

вот передаются такие параметры

play09:36

соответственно сразу на схеме и это

play09:38

Ключевая штука для процесса я это

play09:39

пометил где это не обязательно где

play09:41

какой-то базовый набор данных Мне не

play09:43

важно какие там параметры нет ключевых И

play09:45

это не делаю собственно чувствуете себя

play09:49

свободно мы поговорили с вами про

play09:51

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

play09:54

основные элементы как это нужно все

play09:57

рисовать проектировать самый главный

play10:00

посыл опять же чувствуете себя свободно

play10:02

не ограничивайтесь пусть ваша диаграмма

play10:05

будет Чуть более избыточной чем нужно но

play10:07

зато Понятно для того кого она

play10:09

предназначается

Rate This

5.0 / 5 (0 votes)

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