Sequence Diagram досі жива?!

У сучасній індустрії BA одним з найважливіших компонентів є Sequence Diagram. Вона вважається ледь не найскладнішою частиною UML (Unified Modeling Language), проте досить ефективною та необхідною для аналітики, планування в бізнесі.

Для створення Sequence Diagram необхідно кілька складових:

• Глибинний аналіз та дослідження певної теми.
• Розуміння принципів та правил побудови діаграми.
• Практика: чим більше, тим кращий результат виходитиме в підсумку.

Навіть експерти з багаторічним досвідом іноді припускаються помилок, пов’язаних насамперед з логікою. І ключовою причиною цьому є складність саме Sequence Diagram як інструмента для комплексної BA. І такі помилки є нормою, оскільки дозволяють вчитись та самовдосконалюватись.

Тому не варто хвилюватись, якщо одразу ви не зможете сісти й відмалювати Sequence Diagram. Освоюйте її принципи, основи, практикуйтесь та покращуйте знання. Далі буде простіше. Тим паче, що наші фахівці підготували для вас статтю, в якій розказали детально про цей вид діаграм.

У матеріалі розглянуто наступні питання:

• Що таке взагалі Sequence Diagram.
• Які в ній є елементи та правила.
• Коли найкраще використовувати цю діаграму.
• Які є правила побудови Sequence Diagram.
• Чому Sequence Diagram корисніша за Activity та UseCase діаграми.
• Які є переваги Sequence Diagram для проєктів з активною фазою розробки.

Коротко про головне: цілі та призначення Sequence Diagram

У будь-якій індустрії робота починається з формування цінності. Цінності продукту, послуги, якихось модернізацій тощо. І побудова Sequence Diagram у розрізі BA не є виключенням. Тому фахівцю слід розуміти, для кого і взагалі навіщо він створює цю діаграму.

Для початку моделювання необхідно досконально вивчити:

• канон,
• правила,
• шаблони,
• специфіку,
• стандарти інших систем діаграм.

Також потрібно вчитись експериментувати, не боятись труднощів та потенційних сценаріїв, де вам доведеться схрещувати кілька видів візуалізацій аналізу.

Ключова ціль Sequence Diagram полягає в максимально швидкому донесенні ідеї (думки, доказу) до команди та до клієнта. І для цього всі методи гарні. Потрібно знехтувати правилами чи положеннями – робимо це без вагань.

Далі мова піде про те, коли варто використовувати Sequence Diagram, чому фахівці з BA її не люблять і як взагалі застосовувати цей тип моделювання для вирішення потреб компанії чи клієнта.

Що являє собою Sequence Diagram?

У канонічному сенсі це модель послідовності, де об’єкти впорядковуються за хронологією. В індустрії BA поняття Sequence Diagram набуває нових барв та виглядає наступним чином:

• Це модель послідовності, але в ній об’єкти (чи процеси) взаємодіють.
• Діаграма включає класи та активності, які також взаємодіють.
• Загальна концепція показує принцип взаємодії, послідовність, причини/наслідки тощо.
• Кроки послідовності варіативні й можуть змінюватись за певних умов.
• Уся діаграма має роль певного сценарію, де моделюються варіанти подій, дій, їх наслідків.

Загалом Sequence Diagram показує саме активність певних об’єктів у встановлених проміжках часу (як довготривалі періоди, так і короткі, наприклад, спринти розробки). І акцент в ній робиться на часі, а не на діяльності класів тощо. Окрім того, кожна діаграма орієнтована на єдиний Use Case.

Як на практиці виглядає архітектура Sequence Diagram (спрощено)

Розберімо ключові елементи:

1. Об’єкт (актор). Це необов’язково фізична сутність, можуть бути класи програм, певні функції, модулі системи.
2. Лінія життя. Це визначення має кожен об’єкт і відображає рівень залученості актора в Use Case чи сценарії використання.
3. Активаційна скринька (виклик). Цей блок показує, як довго буде існувати об’єкт у діаграмі. Для запуску блока використовується певний тригер (умова) та виклик, який і активує наступну дію.
4. Синхронні повідомлення. Коли є певний запит і очікується певна відповідь на нього, процес стопориться, допоки ця відповідь не буде отримана. Такий виклик виконується лише один.
5. Асинхронні повідомлення. Команда (чи просто входження інформації) в інший об’єкт без очікування зворотного зв’язку. Таких запитів може бути необмежена кількість (і без урахування черговості об’єктів).
   • Відповіді. Бувають також двох типів, тобто синхронні та асинхронні. У першому випадку система очікує підтвердження для продовження дії, у другому – просто записує дії в логи, не перешкоджаючи процесу використання ресурсу.
6. Завершення (кінець життєвого циклу об’єкта). Деякі актори мають всього одну певну функцію, після виконання якої вони стають не потрібні й мають бути закриті.

Як бачите, Sequence Diagram моделюється виключно в тих випадках, коли описаний фрагмент на 100% робочий та не містить помилок. Ніколи Sequence Diagram не створюється для візуалізації помилок. Проте не завжди це твердження справедливе.

Нюанси Sequence Diagram

Пропонуємо вашій увазі більш деталізований приклад діаграми, який відображає те, наскільки подібні моделі BA можуть бути неоднозначними.

Вона складається з таких елементів:

• Опис дії. Коротке пояснення алгоритму дій користувача (в цьому випадку пошуку чогось). Тут же вказаний і основний розвиток подій, тобто алгоритм, за яким система має реагувати на запит.
• Альтернативний сценарій. Досить нетипове для цього типу діаграм рішення, адже воно описує альтернативу основному алгоритму у випадку, якщо при формуванні запиту була допущена критична помилка.
• Користувач як тригера для виклику об’єктів. Ключовий актор, який і запускає процес обробки даних, активуючи послідовно кілька об’єктів та маніпулюючи ними.
• Чотири актори. Сюди відносяться: сторінки пошуку та пошукової видачі, каталог (база даних), результати пошуку. Всі вони пов’язані між собою й активно обмінюються запитами/відповідями.
• Запити/відповіді. Звернення акторів один до одного з метою конкретизувати, що мав на увазі користувач, та знайти потрібну йому інформацію.

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

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

Окрім наведеного прикладу, в Sequence Diagram є такі поняття:

• LOOP – циклічність, тобто дія, яка виконується постійно в певному проміжку життєвого циклу актора.
• OPT – опційний алгоритм роботи, коли користувач може обрати сам, яким методом виконуватиметься той чи інший процес (типовий приклад – фільтри пошуку).
• ALT – сценарій, при якому у класичному алгоритмі може виникнути помилка, але вона не відобразиться користувачеві, а запустить альтернативний сценарій системи з ціллю нівелювати цю помилку.

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

І взагалі, зазвичай подібного роду моделі орієнтовані на опис (схематичну візуалізацію) невеликого фрагменту (умовно – функціоналу ПЗ). Отже, в рамках проєкту може бути й сотня таких діаграм, але кожна з них буде максимально детально описувати певний компонент (зазвичай дію і її результат).

Різниця між Sequence та Activity діаграмами: кожній свій кейс застосування

Якщо ви працюєте у сфері BA, то досить часто стикаєтесь з питанням, а яку ж обрати діаграму для відображення того чи іншого компоненту. Так, існує безліч варіантів, але найпоширеніші – це вибір між Sequence та Activity. І далі постараємось розібратись, коли і яку з них доцільніше використовувати.

Погляньте уважно на таблицю:

Як бачите, в обох діаграм принципово різні сфери опису. Послідовна орієнтується на дії в проміжку часу, тоді як діаграма активності сфокусована на описі роботи системи (функції) в загальному сенсі.

Щодо обсягів візуалізації, то навіть приклади, наведені в матеріалі, не розкривають повну картину класичної Sequence Diagram. Тому, що зазвичай кількість об’єктів такої візуалізації може бути до 100, як і викликів між ними.

Актуальність Sequence Diagram у 2023-му обумовлена тим, що зростає попит на BA, але уже в класичному розумінні цього терміну. Пояснимо: донедавна роль BA вважалась ледь не гібридом, де фахівець виступав ледь не перекладачем між бізнесом та технічними реалізаторами.

Зараз ця роль повернулась до свого першоджерела, трансформувавшись в базовий BA з традиційними інструментами. Проте це не означає, що експерт не має розбиратись в технічних питання. Трішки, але має.

Плюси, мінуси та підводне каміння Sequence Diagram

Цей тип діаграм не є панацеєю для розв’язання абсолютно всього актуального стека потреб BA, але при цьому вони досить універсальні в плані того, що ви можете конкретизувати певний фрагмент. Тобто такі діаграми короткі, зрозумілі та досить деталізовані.

Серед ключових переваг Sequence Diagram виділяються:

• Візуалізація дій в хронологічному порядку. Кожен виклик, як і відповідь, має свій момент в життєвому циклі певного актора. Тобто ви можете показати, коли саме, як, куди має прийти запит, яка дія виконається та який матиме результат. А також вказати альтернативи чи опційні варіанти алгоритму.
• Візуалізація послідовності (кроків). Схематичне відображення моделі взаємодії з прив’язкою до часової лінії дозволяє відстежити, що і в якому порядку виконується на даному етапі. Тобто куди спрямований виклик, коли він спрямований, що цьому передує та що відбувається далі.
• Візуалізація альтернатив. Цю діаграму можна використовувати як загальне полотно в рамках одного User Case або ділити її на менші частини, описуючи цілком конкретизовані дії. За допомогою тих же OPT чи ALT ви можете показати варіанти, які потенційно можливі, та як в такому випадку має поводитися система.

Це що стосується яскравих плюсів Sequence Diagram. Але навіть ідеальні системи мають недоліки, тому варто звернути увагу і на ці моменти.

До мінусів Sequence Diagram відносять:

• Громіздкість. Кожна діаграма моделюється для певного сценарію використання, не більше. Тому таких візуалізацій може бути досить велика кількість, що автоматично збільшує обсяг роботи, який необхідно провести для детального моделювання всього і вся. І зворотна сторона медалі: далеко не завжди ці діаграми будуть потрібні, тобто є ризик, що ви просто втратите свій час.
• Ситуативність. Так склалося, що раніше ці діаграми застосовувались для моделювання системних потоків. Тобто станом на 2023-й можуть вважатись такими, що не підходять BA (але це залежить безпосередньо від компанії). Тому є ризик, що залучені сторони просто не оцінять подібну модель в розрізі саме BA або попросять змінити тип діаграми на більш оптимальні.
• Складність. Для моделювання цих діаграм вам знадобиться практика. Багато практики, теорії, а потім знову практики. Необхідно розуміти основи, канони, стандарти, дотримуватись їх та вміти виходити за традиційні рамки. Тому поріг входження в процес моделювання Sequence Diagram досить високий, що і викликає ряд труднощів у BA, особливо на початкових етапах кар’єри.

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

Розкривши особливості Sequence Diagram, а також її різницю з Activity Diagram, можемо перейти до ключового питання, а саме, що ж обрати?

Що використовувати для BA, Sequence чи Activity Diagram?

Як ви вже зрозуміли з теми матеріалу, між цими типами діаграм є суттєва різниця, а саме – охоплення ними певних частин розробки і їхніх особливостей. Якщо Sequence Diagram сфокусована на описі хронологічного порядку та прив’язок дій до акторів в конкретний проміжок часу, то Activity Diagram акцентує на процесі та активностях.

Щодо вибору типу діаграми для потреб BA, то тут все досить ситуативно. Перш за все, це залежить від актуальної задачі та її специфіки. Якщо потрібно розкрити певний алгоритм взаємодії компонентів з їх деталізацією черговості запитів та проміжків дій в життєвому циклі сутностей, то оптимально застосовувати Sequence Diagram. Але за умови, що описуємо певний процес в рамках одного короткого сценарію.

Наприклад:

• Логін користувача, де є цілком конкретизований обмін даними в системі.
• Пошуковий запит, де також є конкретика у виклику та відповідях.
• Аутентифікація транзакції, де потрібно підтвердження доступу до коштів та їх наявності.

Фактично ж, таких кейсів можуть бути тисячі, а це лише типовий приклад того, де найчастіше застосовується Sequence Diagram.

Activity Diagram потрібна для моделювання процесу взаємодії між кількома акторами в рамках кількох сценаріїв. Тобто там, де доцільно не деталізувати конкретний алгоритм в розрізі життєвого циклу сутності, а навпаки, поглянути на процес в ширшому плані.

Щодо того, де і коли застосовувати ту чи іншу модель діаграм, відповідь одна: ситуативно, з огляду на потреби проєкту, вимоги зацікавлених осіб тощо.
Принцип вибору Sequence Diagram та кілька рекомендацій з оптимізації процесу розробки візуалізації
Перш ніж починати моделювання тієї чи іншої діаграми, впевніться, що вона відповідає вашим потребам. Для цього можна дати відповідь на ряд питань, наприклад:

• Для чого я це моделюю?
• Мені це сказали зробити, я сам так вирішив?
• Чи є якісь інші причини, умовно – вимоги клієнта?

Вже на цьому етапі ви зрозумієте, яка саме діаграма вам потрібна та як її краще реалізувати. Важливо, щоб всі зацікавлені сторони сприймали її, вміли читати та розуміти подібні графіки.

Окрім цього, важливо, щоб вашу діаграму хтось перевірив до її презентації аудиторії. Насамперед на наявність логічних пропусків та взагалі на якість компонування і деталізацію. Це дозволить нівелювати ефект «тунельного бачення» та заповнити логічні пробіли в діаграмі.

До цього ж рекомендація: залучайте архітекторів, розробників, QA-фахівців до перевірки ваших діаграм. Вони допоможуть вам зламати систему та знайти методи оптимізації. Скорочення, розширення, трансформування – неважливо, головне, що фінальну ітерацію ви зможете презентувати всім зацікавленим особам, які не знайдуть в ній якісь нюанси.

Інша порада: не розтягуйте свою діаграму. Неписане правило моделювання Sequence Diagram говорить, що візуалізація має поміщатись на єдиному аркуші формату A4. За необхідності використайте кілька рівнів діаграми з референсами. Так ви витратите дещо більше часу, проте отримаєте лаконічний та досить детальний результат.

Підсумуємо

Sequence Diagram – це той тип візуалізації з UML, який в контексті BA дозволяє формувати чіткі й деталізовані графіки, що можуть бути використані як для роботи з клієнтом, так і для передачі ідеї технічному відділу.

Ці діаграми завжди вміщають єдиний User Case та є досить короткими. Проте їх кількість може бути доволі значною, якщо ми говоримо про масштабні проєкти чи розгалужений функціонал. Також особливість цих діаграм полягає у їх описі якоїсь дії в хронологічній послідовності та виключно позитивній результативності. Лише у деяких випадках Sequence Diagram може застосовуватись для опису помилки чи апріорі помилкового алгоритму в цілому.

Потенціал цих діаграм розкривається особливо яскраво там, де необхідно показати сценарій, наприклад, застосування умовної дії та очікуваної поведінки системи у відповідь. Щодо решти потенційних алгоритмів, то Sequence Diagram покривають досить значну частину потреб проєкту. Тож варто освоювати цей тип моделювання, якщо ви в ролі BA.

Якщо ви наразі у пошуках навчання, яке дозволило б вам покращити свої знання та навички для успішного виконання ролі бзнес-аналіика, запрошуємо вас долучитися до курсу Business Analysis Intensive Online.