Clean architecture Android - диаграмма Use Case | Чистая архитектура

Рет қаралды 43,095

Күн бұрын

Про Use Case в Clean architecture на Android, показываю на диаграмме и в коде. И подробно объясняю азы чистой архитектуры.
Позаниматься со мной 1 на 1 можно вот тут: ✅ kiparo.com.
СОДЕРЖАНИЕ:
00:00:00 - введение и немного обо мне ;)
00:02:33 - диаграмма Use Case (диаграмма Вариантов использования)
00:16:07 - пример в коде на Java
00:19:01 - основы Clean architecture Android (чистая архитектура)
Найти меня можно вот тут:
✅ На моем сайте: курсы kiparo: kiparo.com
✅ Linkedin: / timofeykovalenko
✅ Instagram: / ttimofey
✅ FB с анонсами видео: / kiparocom
#чистаяархитектура #сleanarchitecture #kiparo

Пікірлер: 129

@TimofeyKovalenko 3 жыл бұрын

СОДЕРЖАНИЕ: 00:00:00 - введение и немного обо мне ;) 00:02:33 - диаграмма Use Case (диаграмма Вариантов использования) 00:16:07 - пример в коде на Java 00:19:01 - основы Clean architecture Android (чистая архитектура)

@berspoland5667 Жыл бұрын

Не один день интернет переворачивают в поисках, вот именно такого объяснения, где все визуализировано и это же показано на коде. Божественная подача. Такого бы спеца в менторы себе. Спасибо огромное. Улетел смотреть далее... 👍

@BigAwl14 Жыл бұрын

Спасибо что есть такие уроки, объясняющие казалось бы базовые вещи простым языком.

@impulsechannel1347 2 жыл бұрын

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

@mikhaillazarev5378 Жыл бұрын

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

@-dubok- Жыл бұрын

Спасибо! И правда, видео очень полезное и проясняющее как логичнее подходить к разработке. Очень захотелось почитать книгу по чистой архитектуре.

@damdinsandanov9745 Жыл бұрын

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

@SleeplessDog-xd8bh 12 күн бұрын

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

@user-ut9lz7zk1m 2 жыл бұрын

Случайно наткнулась на ваше видео, очень понравилось как вы просто и понятно объясняете, лайк и подписка! Спасибо вам за видео =)

@user-ml2xz2pn3p 2 жыл бұрын

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

@CTPEKO3ABPO Жыл бұрын

Хорошо объясняете, понятно и без лишних слов. Спасибо!

@psychosuperlover727 Жыл бұрын

Это просто шикарное видео, решил подтянуть теорию и не прогадал с выбором, спасибо!

@cinderellarouge 2 жыл бұрын

Я вам очень благодарна, Тимофей!Лайк!С новым годом вас!

@azatsabirov863 2 жыл бұрын

Спасибо! Слушать и учиться - одно удовольствие!

@TimofeyKovalenko 2 жыл бұрын

😀

@arthurtargonsky9952 3 жыл бұрын

Тимофей, спасибо за видео! Для меня, как начинающего специалиста, прекрасно изложен материал :)

@olegkovalenko5708 2 жыл бұрын

Спасибо за труды)) очень полезно!

@shakhriyarbadalov5628 11 ай бұрын

Спасибо Тимофей. Уроки очень полезны и интересны )))

@artonext 2 жыл бұрын

Спасибо за релевантную информацию...было интересно плюс хорошая подача продолжай!!

@artlinestudio6735 2 ай бұрын

Очень крутой урок. Очень полезная информация! Лайк и подписка. Спасибо учитель.

@newsystem4571 2 жыл бұрын

Отличное видео и очень комфортно слушать.

@user-we6si4mi3x 4 ай бұрын

Тимофей, большое спасибо за урок!!!

@OCEH6 Жыл бұрын

Очень круто! Огромное спасибо!

@yakogdan Жыл бұрын

Спасибо за видео! Всё очень понятно.

@sergozubarev1153 2 жыл бұрын

Спасибо за труды!

@user-pe5cm1ks7b 11 ай бұрын

Полезное видео, спасибо. Особенное спасибо за использование диаграммы :)

@maksy3398 2 жыл бұрын

спасибо большое, прям вот то что нужно, отличная подача материала)

@TimofeyKovalenko 2 жыл бұрын

😉

@GriNAME 2 жыл бұрын

Большое спасибо! Очень полезно!

@Serdjom1986 Жыл бұрын

Спасибо автору, очень просто и полезно объяснил. Понял все с первого раза!

@hackim2554 2 жыл бұрын

Спасибо за видео, много чего нового узнал для себя : )

@yuriivytivskyi350 2 жыл бұрын

Спасибо за видео, это было очень полезно)

@stasleonov5196 Жыл бұрын

Очень здорово, большое спасибо

@user-il4ow8rp3n Жыл бұрын

Очень полезное видео!Спасибо!

@09GorecGorecGorecGorecGorecGor Жыл бұрын

Спасибо, очень понятное объяснение

@Majjabee-np9nq 2 жыл бұрын

Очень круто! Наконец то начал понимать Клин)

@TimofeyKovalenko 2 жыл бұрын

😉

@user-yl1mf6gx3t Жыл бұрын

Спасибо, очень полезно и понятно.

@user-fj1hs9sr9u 2 жыл бұрын

спасибо! ваши видео очень интересно смотреть.

@TimofeyKovalenko 2 жыл бұрын

😉

@nikson9334 4 ай бұрын

Ну да, когда пишешь класс думаешь эгоистично .. типа ну мне-то понятно почему в нём столько функций ) постепенно переучиваешься

@user-hx9ur3qr2q 9 ай бұрын

Спасибо большое! Помогло.

@kaylas2971 2 жыл бұрын

Для меня очень интересно было!!!

@anunnaj 2 жыл бұрын

Очень полезно! Даже сказал бы сверхполезно) спасиб

@sovrinfo 2 жыл бұрын

Спасибо за видео.Коммент в поддержку!

@TimofeyKovalenko 2 жыл бұрын

Спасибо)

@ulugg3529 2 жыл бұрын

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

@sergiomatiash5977 2 жыл бұрын

Суперски, спасибо

@Alpha16212 2 жыл бұрын

Тимофей, спасибо!!

@break8090 2 жыл бұрын

Огромное спасибо.

@user-ke3jt3uh3m 3 жыл бұрын

Как абстрагированный пример с Use Case всё супер круто и понятно изложено, спасибо большое) Но как быть с данными, которые нужны этому useCase? Например ему нужна какая-то сущность из бд. В каком виде её передавать в useCase? Как данные возвращать? В каком виде? Как это дело правильно мапить? Как domain слою общаться с presentation и model? Как реализовывать правило зависимостей на практике? В общем довольно много вопросов по clean'у)) Тянет на полноценный курс лекций. Идеальным вариантом было бы конечно на практике от А до Я разобрать проект и как его правильно строить по clean. Жду продолжения:) Спасибо автору за работу, очень прикольное изложение материала!

@TimofeyKovalenko 3 жыл бұрын

В следующих видео это все будет :). А если в краце, то никто не запрещает в конструктор UseCase что то передать, например интерфейс за которым прячется реализация работы с базой или нетворком.

@roustamdev Жыл бұрын

Спасибо!

@user-sq5cr5uq8i 2 жыл бұрын

Очень полезно!!!

@user-dj2vx6nb5h 2 жыл бұрын

Спасибо 👍🏻🔥

@KO3Jlbl Жыл бұрын

Хороший комментарий, спасибо!

@tcyniktcynik2545 Жыл бұрын

Это было очень полезно. Ваш контент оставляет только один вопрос: почему на канале так мало подписчиков???

@muhammadkurbonov4779 Ай бұрын

Спасибо большое

@Arman_127 2 жыл бұрын

Большое спасибо

@sonar_devices 3 жыл бұрын

Большое спасибо!

@TimofeyKovalenko 2 жыл бұрын

незачно ;)

@serggio88888 3 жыл бұрын

Спасибо

@abuiman5251 2 жыл бұрын

Спасибо!!!

@user-yf9fz8zr7r 2 ай бұрын

Было очень полезно, красава! Яху

@user-tc4db8su3b 2 жыл бұрын

Очень полезно, на мой взгляд материал изложен достаточно подробно. Спасибо!

@user-ml7lb2xr2n Ай бұрын

Огромное спасибо за ролик!) Правда год 2021, а классы почему-то на Java ))

@user-kk1yi2sz1d 2 жыл бұрын

спасибо

@samuilzhumakhanov6056 2 жыл бұрын

Было очень полезно, спасибо. Только можно, пожалуйста, на котлине)

@TimofeyKovalenko 2 жыл бұрын

Дальше все видео на Koltin ).

@Majjabee-np9nq 2 жыл бұрын

Весьма доступно! Еще видео будет?

@TimofeyKovalenko 2 жыл бұрын

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

@user-el3ek3wt9s 2 жыл бұрын

То чувство, когда учишь язык 3 месяца, а потом выясняется, что надо было с архитектуры начинать) Спасибо, было полезно, пошел все переделывать!)

@tpov_oleg 2 жыл бұрын

Вообще-то наоборот, архитектура намного сложнее, ну да ладно

@user-el3ek3wt9s 2 жыл бұрын

@@tpov_oleg она-то сложнее, я не спорю. Но без неё все равно нормального кода не напишешь.

@kavelquu Жыл бұрын

@@user-el3ek3wt9s А со знаниями архитектуры, но без нормальных знаний языка, вообще ничего не напишешь)

@user-yp1rp6qs5v 4 ай бұрын

Спасибо за работу, очень доходчиво. Хотелось бы уточнить, проектируя архитектуру приложения мы всегда ориентируемся на взамодействие с пользоателем, как в данном видео (use case) или есть еще варианты?

@TimofeyKovalenko 3 ай бұрын

Use Case не обязательно решает проблему пользователя, это может быть какае-то внутренняя функциональность. Просто мобилка в большинсве случаев это клиентское приложение, поэтому вся бизнес логика это как правило решение так или иначе проблем пользователя.

@vitalijuskolinko9011 2 жыл бұрын

Спасибо вам, очень полезная информация. Среди комментариев я видел вопрос по поводу использования use case'ов в виде singleton. Ответ понятен. А какое ваше мнение по поводу использования в виде интерфейсов? Т.е. имеет ли смысл так делать и писать имплементации юзкейсов? Бывают ли ситуации в реальных проектах, чтобы поиходилось менять имплементацию и не затрагивать другую логику? А также тестируются ли юзкейсы? Например, через DI инжектить имплементацию и её менять на тестовую для тестирования?

@TimofeyKovalenko 2 жыл бұрын

На мой взгляд делать с интерфейсами особого смысла нет, очень наврят ли у вас будет несколько имплементаций, а если и будет, можно сделать только в необходимых местах. Юз кейсы покрываются тестами обязательно, но DI тут не нужен. Вообще старайтесь не затаскивать в тесты лишнее, просто берите объект юз кейса и тестите, если нужно протестить класс, где используется юз кейс, делайте мок на основе класса юз кейса и все.

@user-ix7lb1sx4k 2 жыл бұрын

Здравствуйте. Урок по автогенерации кода из модели есть?

@alex_ku_san 2 жыл бұрын

Спасибо, полезно. 1. Тема про то зачем нужны отдельные классы для юзкейсов не раскрыта, неужели все дело в инкапсуляции? Я могу и функцию создать приватную с одним "юзкейсом". 2. А вот что особенно мне понравилось это наглядная привязка юзкейсов на диаграмме к UI-приложению, так действительно удобно проектировать функционал

@TimofeyKovalenko 2 жыл бұрын

1. Дело в SOLID. А точнее в принципе единой ответсвенности. Один класс одна ответственность, если делать много паблик методов, вероятнее всего это приведет к нарушению данного принципа.

@juneuniversum 2 жыл бұрын

Попытаюсь раскрыть за автора. Тут дело не столько в SOLID. Если коротко: классы нужны, чтобы сделать "частичное применение функции" (забиндить аргументы) Юзкейсы - это фактически обычные функции, и могут быть ими заменены (потому что у usecase всегда один метод, и usecase всегда stateless). Но у юзкейсов есть зависимости, которые нужно инжектить. Если бы юзкейсы были бы функциями, то нам пришлось бы поставлять зависимости прямо в месте вызова - и так делать было бы очень не удобно. Если бы у нас был JS, то мы бы сделали просто bind аргументов. Но Java/Kotlin так сделать нельзя (точнее геморно). Поэтому юзкейсы просто сделали классами. DI-фреймворк создает их и автоматически инжектит нужные зависимости, а мы уже вызываем его где нам нужно, не думая о зависимостях ничего. Если бы DI умели бы прозрачно инжектить прямо в функции, то думаю юзкейсы были бы функциями, а не классами.

@alex_ku_san 2 жыл бұрын

@@TimofeyKovalenko если следовать такому подходу, то придется каждую функцию выносить в отдельный класс, что странно и неудобно, и вряд ли кто-то так делает S-принцип, он скорее про разделение ответственности относительно пользователей (Вы когда нибудь делали приложение у которого несколько типов пользователей? Там понимание принципа становится однозначным. Это больше похоже на разделение интерфейсов, только с другой стороны, т.е. получается разделение реализации) В общем наличие в классе нескольких функций не обязательно нарушает этот принцип

@alex_ku_san 2 жыл бұрын

@@juneuniversum тоже к этому пришел, благодарю за подробный ответ :)

@witiania Жыл бұрын

Добрый день, очень клевый ролик с доступным объяснением, почему не объясняете сразу на Котлин а на джаве? еще вопрос, для построения приложения мы используем либо clean либо например MVVM или мы и то и то используем в одном приложении? И еще вопрос, когда откроется набор на курсы?

@TimofeyKovalenko Жыл бұрын

Посмотрите все остальные ролики, там есть ответы на все эти вопросы ;)

@ivantrushin3445 2 жыл бұрын

эх, выходил бы этот цикл видео, когда я писал диплом... Было бы сто крат легче со всем разбираться

@bunnyrin Жыл бұрын

Это опен-сорс проект в видео? Может кто-то скинуть ссылку на Гитхаб проекта?

@rinatislamov8977 Жыл бұрын

Здравствуйте, расскажите какая логика в useCase. Если я получил список из интернета и хочу сделать по нажатию кнопки сортировку или поиск, локально на устройстве не отправляя запрос в сеть. Надо писать логику в useCase или в viewModel? Надо писать в useCase только логику которая связана с data слоем?

@TimofeyKovalenko Жыл бұрын

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

@STRElok104 2 жыл бұрын

Не знаю увидите или нет мой комментарий стало интересно! Урок у вас отличный, но появился вопрос: вы сказали что clean architecture это когда один класс выполняет одну функцию, но разве это в целом не относится к принципу SOLID а конкретно к Single Responisibility?

@TimofeyKovalenko 2 жыл бұрын

Сам по себе, клин - это немного другое, это описание структуры и взаимодействия разных частей приложения, то есть более глобальная штука. И естественно при реализации клин мы используем различные паттерны и в том числе следуем принципам SOLID. Одно другое дополняет ;)

@user-el3ek3wt9s 2 жыл бұрын

Как всегда, проблема упрощенных примеров - они не отображают суть реальных кейсов) В данном случае юзкейс GetMovieImagesByPage выполняет функцию RecyclerViewAapter'а или просто поставляет ему готовый ArrayList для загрузки? Какую роль тогда выполняет адаптер - он является частью бизнес логики или принадлежит к какой-то другой части архитектуры?)) Не поймите неправильно, видео классное, но вопросов стало больше, чем было до просмотра)

@sashainverse1252 Жыл бұрын

Есть много классов UseCase, в каждом из которых есть один публичный метод execute. А нет ли здесь нарушения принципа DRY? Эти методы execute обладают самой разнообразной сигнатурой. Поэтому спрятать их за общим интерфейсом-прародителем interface UseCase { fun execute() } - затруднительно

@TimofeyKovalenko Жыл бұрын

Вы можете сделать параметризированный базовый класс с входящим и исходящим параметром. DRY тут не нарушается, каждый UseCase - это отдельная логика, в чем тут проблема? Повторяется название метода, это не проблема. Можете не execute назвать, это не важно. Это просто устоявшееся название, а не строгое правило

@plumaabigarrada5906 Жыл бұрын

Тимофей, к сожалению, не нашёл ссылки на первоисточники о чистой архитектуре и юзкейсах в этой серии видео. Не могли бы вы перечислить их? Книги, неапример, или известные статьи...

@TimofeyKovalenko Жыл бұрын

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

@starcadster 2 жыл бұрын

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

@TimofeyKovalenko 2 жыл бұрын

1) Синглтонами в целом лучше не злоупотреблять 2) Реальной пользы от того, что Use Case станет синглтоном, нет никакой, Use Case не хранит никакого состояния, которое необходимо делить между разными клиентами (если у вас хранит, значит с этим Use Case что-то не так) 3) Если Use Case будет синглтоном, значит он будет всегда висеть в памяти, даже тогда когда он уже не нужен, а юз кейсов может быть очень много в приложении 4) С UseCase синглтоном потенциально могут быть проблемы, например один клиент поиспользовал логику юз кейса и оставил там артефакты (какие-то данные, состояние и тд), соответсвенно все это достанется другому клиенту, хотя и не должно 5) Ну и сама суть юз кейса в том, что он обслуживает конкретного клиента, а не всех подряд. Да, оперируем ими как сушностями, но не вижу в этом никаких проблем, синглон намного больше проблем добавит.

@user-xq2ng2cu3d Жыл бұрын

а можно ли наследовать usecase если хочешь избежать дублирования кода. Ну или композировать

@TimofeyKovalenko Жыл бұрын

Я не очень люблю использовать наследование для шаринга общего функционала, лучше вынесете общие части в отдельный класс

@funnymoment9164 3 жыл бұрын

А если из Репозитория передавать результат запроса в сеть, то нужно под результат запроса тоже создавать отдельный UseCase или можно в том же UseCase? При том что успешно полученные данные не получаются через результат запроса в методе из репозитория , т.к. данные получаются из базы данных, в которую репозиторий их запишет.

@TimofeyKovalenko 3 жыл бұрын

Не совсем понял вас. У вас есть UseCase у которого есть метод с входящими и исходящими(return) данными. Зачем вам отдельный UseCase для возврата данных?

@funnymoment9164 3 жыл бұрын

@@TimofeyKovalenko Да. В одном usecase 2 функции, одна - обращается в репозиторий для запроса в сеть, а другая - передает во ViewModel результат запроса в сеть, если произошла ошибка. Это неправильный подход?

@TimofeyKovalenko 3 жыл бұрын

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

@funnymoment9164 3 жыл бұрын

@@TimofeyKovalenko class GetCurrentWeatherFromNetworkUseCase @Inject constructor( private val repository: IRepositoryCurrentWeather ) { var getNetworkResponseResult: LiveData = repository.networkResponseResult suspend fun getCurrentWeather() { repository.getCurrentWeather() } }

@TimofeyKovalenko 3 жыл бұрын

@@funnymoment9164 Так: 1) Использовать LiveData в UseCase крайне не желательно, так как это все же андроидовская штука, а UseCase не должен иметь ничего общего с платформенными фичами. 2) UseCase должен содержать только один публичный метод. 3) Можно ведь вот так сделать: class GetCurrentWeatherFromNetworkUseCase @Inject constructor( private val repository: IRepositoryCurrentWeather ) { suspend fun getCurrentWeather(): ResultWrapper { return repository.getCurrentWeather() } } А еще лучше назвать метод: suspend fun execute(): ResultWrapper {} ну либо suspend fun get(): ResultWrapper {}. Так как весь смысл того, что делает данный метод уже есть в названии класса.

@Animalfox Ай бұрын

Я согласен с тем что необходимо рисовать диаграммы, но хотелось бы получить полную информацию о том как это делать, какие правила построения и оформления этих диаграмм, а не просто поиметь посыл - "делайте так, но это черновик". Не согласен с расположением UseCase в Domain области, так как это уже не чистая архитектура, а DDD (Domain Driven Design) чистая архитектура. Этот вариант расположения предусматривает создание бизнес правил внутри домена, но вносит тем самым путаницу с взаимосвязями - при использовании Clean Architecture + DDD проект становится подвержен неправильному направлению связей классов, его становится сложнее поддерживать, так как необходимо все время контролировать вручную верно ли располагаются связи, или же мы допускаем ошибку. Рефакторить приходится чаще, обслуживание проекта становится дороже. Clean Architecture предполагает же наоборот уровень ядра (Core) в который входит Domain и Application, а внутри Application находятся UseCase. Это гарантирует правильное строение взаимосвязей классов, благодаря которому проект становится проще обслуживать.

@tpov_oleg 2 жыл бұрын

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

@TimofeyKovalenko 2 жыл бұрын

Да, 50 классов. Но если у вас действительно, есть такая "супер активити", то тут вопрос к тому, точно ли приложение сделано правильно, может не нужно на одной активити столько функционала? ;)

@tpov_oleg 2 жыл бұрын

@@TimofeyKovalenko да, 36 в активити на 1200 строк и 10 в вьюмодель. Так а для других активити нужно другие юзкейсы?

@TimofeyKovalenko 2 жыл бұрын

Что значит другие юз кейсы? Если вам нужен один и тот же юз кейс в нескольких активити, то переиспользуете его, юз кейсы же не привязаны к активити, они живут своей жизнью).

@warflow 2 жыл бұрын

Ссылку на приложение не нашёл, оно open source ? p.s. нашёл но комменты со ссылками удаляют, не смогу поделится

@TimofeyKovalenko 2 жыл бұрын

ссылки на приложение не давал, пишите сами по примеру из видео, иначе толку не будет ;)

@warflow 2 жыл бұрын

@@TimofeyKovalenko я про приложение movie Кстати там не разделено всё по папкам на domain data, трудно ориентироваться

@TimofeyKovalenko 2 жыл бұрын

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

@mvalexeev Жыл бұрын

Посмотрел первое видео. Если в таком духе и дальше объяснения, то лет так через десять новичкам -можно- нужно будет все это выкинуть и начинать смотреть нормальные курсы. Так и появляется индусский стиль программирования - с неверно выбранного курса. ДА выглядит просто, НО по факту - лажа. GetMovieByPage))

@TimofeyKovalenko Жыл бұрын

Предложите свой вариант и расскажите подробнее почему вы считаете, это не правильным. С удовольствием поболтаю)

@AntonP230 Жыл бұрын

При всем уважении, отличный материал, но автору нужно поработать над краткостью речи :-) По 2-3 минуты объяснять, то почему он не будет объяснять тот или иной аспект, ну такое...

@networksx333 2 ай бұрын

Знаете, намного чаще приятнее слушать тех, кто всё разжевывает, чем тех, кто скачет с вопроса на вопрос. Ведь лучше 3 минуты послушать одно и то же, чем потом 30 пытаться понять, что же имел в виду автор

@Vepr12Molot Жыл бұрын

Даже для простейшего приложения с 2мя экранами на диаграмме с десяток "яиц", а теперь представь, что будет с приложением чуть посложнее? Основной косяк данного повествования - это совершенно не раскрыт момент многоуровневости диаграмм! Есть закон восприятия информации, по которому должно быть не более 7, в очень крайнем случае 10 элементов в любом списке. Поэтому сначала рисуется диаграмма верхнего уровня, при клике по кейсам которой проваливаешься в кейсы нижнего уровня. В данном примере для логина 1 кейс, для регистрации 1 кейс и при клике по ним уже показываются всякие логины через пейсбуки и пр. И не рисуй стрелки ИЗ актора! Стрелка начинается рядом с ним. А то аналитик какой-нибудь увидит и сдохнет от смеха. Жалко их все-таки, тоже ведь человеки :)))

@TimofeyKovalenko Жыл бұрын

Вот только видео я делаю не для аналитиков или профессоров UML)))