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

Діаграма взаємодії

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

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

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

• Позначення діаграми послідовності
• Актори
  • Лінії життя
  • Повідомлення
  • Створити повідомлення
  • Видалити повідомлення
  • Самоповідомлення
  • Відповідь на повідомлення
  • Знайдено повідомлення
  • Загублене повідомлення
  • Охоронці
• Як створити діаграми послідовностей?
• Випадки використання діаграм послідовностей
• Проблеми використання діаграм послідовностей

1. Позначення діаграми послідовності

1.1. Актори

Актор на діаграмі UML представляє тип ролі, де він взаємодіє з системою та її об’єктами. Тут важливо зазначити, що актор завжди знаходиться поза межами системи, яку ми прагнемо змоделювати за допомогою діаграми UML.

Ми використовуємо акторів для зображення різних ролей, включаючи користувачів та інших зовнішніх суб’єктів. Ми представляємо актора на діаграмі UML, використовуючи нотацію особи. На діаграмі послідовності може бути кілька акторів.

Наприклад:

Тут користувач у системі бронювання місць показаний як актор, якщо він існує поза системою і не є частиною системи.

1.2. Лінії життя

Лінія життя — це іменований елемент, який зображує окремого учасника на діаграмі послідовності. Отже, в основному кожен екземпляр на діаграмі послідовності представлений лінією життя. Елементи лінії життя розташовані у верхній частині діаграми послідовності. Стандарт UML для іменування лінії життя має наступний формат:

Ім'я екземпляра: Ім'я класу

фрагмент java

Зображуємо лінію життя в прямокутнику, який називається голова з його назвою та типом. Голова розташована на верхній частині вертикальної пунктирної лінії (називається ніжкою), як показано вище.

• Якщо ми хочемо змоделювати екземпляр без назви, ми дотримуємося того самого шаблону, за винятком того, що тепер частина назви lifeline залишається порожньою.
• Різниця між рятувальним кругом і актором
  • Лінія життя завжди зображує внутрішній по відношенню до системи об’єкт, тоді як актори використовуються для зображення зовнішніх по відношенню до системи об’єктів.

Нижче наведено приклад діаграми послідовності:

1.3. Повідомлення

Зв'язок між об'єктами зображується за допомогою повідомлень. Повідомлення з’являються в послідовному порядку на лінії життя.

• Зображуємо повідомлення за допомогою стрілок.
• Лінії життя та повідомлення складають ядро ​​діаграми послідовності.

Повідомлення можна розділити на такі категорії:

Синхронні повідомлення

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

• Велика кількість викликів в об'єктно-орієнтованому програмуванні є синхронними.
• Ми використовуємо a суцільна головка стріли для представлення синхронного повідомлення.

Асинхронні повідомлення

Асинхронне повідомлення не чекає відповіді від отримувача. Взаємодія продовжується незалежно від того, обробив одержувач попереднє повідомлення чи ні. Ми використовуємо a викладена наконечник стріли для представлення асинхронного повідомлення.

1.4. Створити повідомлення

Ми використовуємо повідомлення Create для створення нового об’єкта на діаграмі послідовності. Бувають ситуації, коли певний виклик повідомлення вимагає створення об'єкта. Він представлений пунктирною стрілкою та словом створення, позначеним на ньому, щоб вказати, що це символ створення повідомлення.

Наприклад:

Створення нового замовлення на веб-сайті електронної комерції вимагатиме створення нового об’єкта класу Order.

1 до 100 римських №

1.5. Видалити повідомлення

Ми використовуємо Delete Message, щоб видалити об’єкт. Коли об’єкт звільняється від пам’яті або знищується в системі, ми використовуємо символ «Видалити повідомлення». Він знищує наявність об’єкта в системі. Він представлений стрілкою, що закінчується х.

Наприклад:

У наведеному нижче сценарії, коли користувач отримує замовлення, об’єкт класу замовлення може бути знищено.

1.6. Самоповідомлення

Можуть виникнути певні сценарії, коли об’єкт повинен надіслати повідомлення самому собі. Такі повідомлення називаються власними повідомленнями та позначаються символом a U-подібна стрілка .

Інший приклад:

Розглянемо сценарій, коли пристрій хоче отримати доступ до своєї веб-камери. Такий сценарій представлено за допомогою власного повідомлення.

1.7. Відповідь на повідомлення

Повідомлення-відповіді використовуються, щоб показати повідомлення, яке надсилається від одержувача до відправника. Ми представляємо повідомлення повернення/відповіді за допомогою відкрита головка стріли з пунктирною лінією . Взаємодія продовжується лише тоді, коли одержувач надсилає повідомлення-відповідь.

Наприклад:

пошук bfs

Розглянемо сценарій, коли пристрій запитує фотографію від користувача. Тут повідомлення, яке показує надіслане фото, є повідомленням-відповіддю.

1.8. Знайдено повідомлення

Повідомлення «Знайдено» використовується для представлення сценарію, коли невідоме джерело надсилає повідомлення. Він представлений за допомогою стрілка, спрямована до лінії життя від кінцевої точки.

Наприклад:

Розглянемо сценарій апаратного збою.

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

1.9. Загублене повідомлення

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

Наприклад:

Розглянемо сценарій, коли генерується попередження.

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

1.10. Охоронці

Для моделювання умов ми використовуємо захисники в UML. Вони використовуються, коли нам потрібно обмежити потік повідомлень під приводом виконання умови. Охоронці відіграють важливу роль, повідомляючи розробникам програмного забезпечення про обмеження, пов’язані з системою чи певним процесом.

Наприклад:

Для того, щоб мати можливість зняти готівку, наявність балансу більше нуля є умовою, яка має бути виконана, як показано нижче.

Наведена вище діаграма послідовності зображує діаграму послідовності для музичного програвача на основі емоцій:

1. Спочатку програму відкриває користувач.
2. Потім пристрій отримує доступ до веб-камери.
3. Веб-камера знімає зображення користувача.
4. Пристрій використовує алгоритми для визначення обличчя та прогнозування настрою.
5. Потім він запитує базу даних для словника можливих настроїв.
6. Настрій витягується з бази даних.
7. Настрій відображається користувачеві.
8. Музика запитується з бази даних.
9. Список відтворення створюється і нарешті показується користувачеві.

2. Як створити діаграми послідовностей?

Створення діаграми послідовності включає кілька етапів, і зазвичай це робиться на етапі проектування розробки програмного забезпечення, щоб проілюструвати, як різні компоненти або об’єкти взаємодіють з часом. Ось покрокова інструкція щодо створення діаграм послідовності:

1. Визначте сценарій:
   • Зрозумійте конкретний сценарій або варіант використання, який ви хочете представити на діаграмі послідовності. Це може бути конкретна взаємодія між об’єктами або потік повідомлень у конкретному процесі.
2. Перелік учасників:
   • Визначте учасників (об’єкти чи актори), які беруть участь у сценарії. Учасниками можуть бути користувачі, системи або зовнішні сутності.
3. Визначте лінії життя:
   • Намалюйте вертикальну пунктирну лінію для кожного учасника, що представляє лінію життя кожного об’єкта в часі. Лінія життя представляє існування об'єкта під час взаємодії.
4. Розташуйте лінії життя:
   • Розташуйте лінії життя горизонтально в порядку їх участі у взаємодії. Це допомагає візуалізувати потік повідомлень між учасниками.
5. Додайте панелі активації:
   • Для кожного повідомлення намалюйте смужку активації на лінії життя учасника, який надсилає. Панель активації відображає тривалість часу, протягом якого учасник активно обробляє повідомлення.
6. Малювати повідомлення:
   • Використовуйте стрілки для позначення повідомлень між учасниками. Повідомлення протікають горизонтально між лініями життя, вказуючи на зв’язок між об’єктами. Різні типи повідомлень включають синхронні (суцільна стрілка), асинхронні (пунктирна стрілка) і власні повідомлення.
7. Включати зворотні повідомлення:
   • Якщо учасник надсилає повідомлення-відповідь, намалюйте пунктирну стрілку, яка повертається до вихідного відправника, щоб представити повідомлення-відповідь.
8. Вкажіть час і порядок:
   • Використовуйте цифри, щоб вказати порядок повідомлень у послідовності. Ви також можете використовувати вертикальні пунктирні лінії для представлення подій або плину часу.
9. Додайте умови та цикли:
   • Використовуйте комбіновані фрагменти для представлення умов (наприклад, операторів if) і циклів у взаємодії. Це ускладнює діаграму послідовності та допомагає деталізувати потік керування.
10. Розглянемо паралельне виконання:
    • Якщо відбуваються паралельні дії, відобразіть їх, накресливши паралельні вертикальні пунктирні лінії та розмістивши повідомлення відповідно.
11. Перегляньте та уточніть:
    • Перегляньте діаграму послідовності на ясність і правильність. Переконайтеся, що він точно представляє заплановану взаємодію. Уточніть за потреби.
12. Додайте анотації та коментарі:
    • Включіть будь-яку додаткову інформацію, анотації або коментарі, які надають контекст або роз’яснення для елементів на схемі.
13. Припущення та обмеження документа:
    • Якщо є якісь припущення або обмеження, пов’язані з взаємодією, задокументуйте їх разом із схемою.
14. Інструменти:
    • Скористайтеся інструментом моделювання UML або програмним забезпеченням для створення діаграм, щоб створити акуратну та професійно виглядаючу діаграму послідовності. Ці інструменти часто пропонують функції для легкого редагування, співпраці та документування.

3. Випадки використання діаграм послідовностей

• Візуалізація поведінки системи:
  • Діаграми послідовності використовуються для ілюстрації динамічної поведінки системи, показуючи взаємодію між різними компонентами, об’єктами або суб’єктами з часом.
  • Вони забезпечують чітке та візуальне представлення потоку повідомлень і подій у певному сценарії.
• Дизайн та архітектура програмного забезпечення:
  • На етапі проектування розробки програмного забезпечення діаграми послідовності допомагають розробникам і архітекторам планувати та розуміти, як різні компоненти та об’єкти взаємодіятимуть для виконання певних функцій.
  • Вони надають схему поведінки системи.
• Спілкування та співпраця:
  • Діаграми послідовності служать інструментом спілкування між зацікавленими сторонами, включаючи розробників, дизайнерів, менеджерів проектів і клієнтів.
  • Вони допомагають передати складну взаємодію в легкому для розуміння візуальному форматі, сприяючи співпраці та спільному розумінню.
• Роз'яснення вимог:
  • Під час уточнення системних вимог можна використовувати діаграми послідовності, щоб уточнити та визначити очікувані взаємодії між компонентами системи або між системою та зовнішніми об’єктами.
  • Вони допомагають забезпечити загальне розуміння поведінки системи серед усіх зацікавлених сторін.
• Налагодження та усунення несправностей:
  • Розробники використовують діаграми послідовності як інструмент налагодження для виявлення та аналізу проблем, пов’язаних із порядком і часом повідомлень під час взаємодії системи.
  • Він надає візуальне представлення потоку керування та допомагає знаходити та вирішувати проблеми.

4. Проблеми використання діаграм послідовностей

• Складність і розмір:
  • Оскільки системи ускладнюються, діаграми послідовності можуть ставати великими та заплутаними. Керувати розміром діаграми, водночас точно відображаючи взаємодії, може бути складно, а надто складні діаграми може стати важко зрозуміти.
• Рівень абстракції:
  • Знайти правильний баланс з точки зору абстракції може бути складно. Діаграми послідовності мають бути достатньо детальними, щоб передати необхідну інформацію, але занадто багато деталей може перевантажити читачів. Важливо зосередитися на найважливіших взаємодіях, не занурюючись у дрібниці.
• Динамічний характер:
  • Діаграми послідовності представляють динамічні аспекти системи, і, як наслідок, вони можуть часто змінюватися в процесі розробки. Підтримувати діаграми послідовності в актуальному стані в системі, що розвивається, може бути складно, особливо в швидко мінливих або гнучких середовищах розробки.
• Двозначність у повідомленнях:
  • Іноді буває складно визначити точний характер повідомлень між об’єктами. Неоднозначність у змісті або значенні повідомлення може призвести до непорозумінь серед зацікавлених сторін і вплинути на точність діаграми послідовності.
• Одночасність і паралелізм:
  • Представлення одночасних і паралельних процесів може бути складним. У той час як діаграми послідовності мають механізми, які вказують на паралельне виконання, візуалізація кількох взаємодій, що відбуваються одночасно, може бути складною справою та може потребувати додаткових елементів діаграми.
• Обмеження реального часу:
  • Відображення обмежень у реальному часі та точних вимог до часу може бути складним завданням. Хоча діаграми послідовності забезпечують послідовне представлення, точне захоплення та передача аспектів у реальному часі може вимагати додаткової документації або додаткових діаграм.