1. Діаграма послідовності UML Для чого використовується метод проектування
2. План дій
3. Зауваження (опис)
4. Як застосовувати техніку креативності
5. CRC-картки
6. як навчитися
7. приклад використання
8. Створення та видалення учасників
9. Діаграма послідовності: цикли, умови тощо

Діаграма послідовності UML

Для чого використовується метод проектування

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

План дій

У розділі «Опис» вивчіть основний набір символів діаграми послідовності, необхідний для того, щоб вміти читати діаграми.

Після ознайомлення з іншими розділами ( «Приклад», «Застосування») ви можете спробувати свої сили в самостійному складанні діаграм послідовності.

Зауваження (опис)

Тут представлений основний набір символів діаграми послідовності, необхідний для того, щоб зуміти прочитати діаграму. Після ознайомлення з іншими розділами ( «Приклад», «Застосування») ви зможете складати діаграми послідовності самостійно!

ТермінЗображенняОпис

Знайдене повідомлення У першого повідомлення немає учасника, Хто послав Мене, оскільки воно приходить з невідомого джерела. Воно називається знайденим повідомленням (found message). Повідомлення Команда, що відправляється іншому учаснику. Може містити тільки дані, що передаються. Лінія життя Кожна лінія життя має смугу активності, яка показує інтервал активності учасника при взаємодії. Вона відповідними ет часу знаходження в стеці одного з методів учасника. У мові UML смуги активності не обов'язкові, але я вважаю їх виключно зручними при поясненні поведінки.

учасник У більшості випадків можна вважати учасників діаграми взаємодії об'єктами, як це і було в дійсності в UML 1. Але в UML 2 їх роль значно складніше. Тому тут вживається термін учасники (participants), який формально не входить в специфікацію UML. Самовизов Учасник відправляє повідомлення (команду) самому собі. повернення Передача управління назад учаснику, який до цього ініціював повідомлення. Активація На зображенні це - білий вертикальний прямокутник. Момент, коли учасник починає діяти у відповідь на отримане повідомлення. створення У разі створення учасника треба намалювати стрілку повідомлення, на правління до прямокутника учасника. Якщо застосовується конст руктор, то ім'я повідомлення не обов'язково, але можна маркувати його словом «new» в будь-якому випадку. Якщо учасник виконує що-небудь безпосередньо після створення, наприклад команду запиту, то треба
почати активацію відразу після прямокутника учасника. самоудаленіе Видалення учасника позначається великим хрестом (X). X в кінці лінії життя показує, що учасник видалити ет сам себе. Видалення з іншого об'єкта Видалення учасника позначається великим хрестом (X). Стрілка пові домлення, що йде в X, означає, що один учасник явно уда ляє іншого. фрейми взаємодії

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

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

Діаграма послідовно ності застосовується для візуалізації процесу взаємодії об'єктів, а не як засіб моделювання алгоритму управління.
Як було сказано, існують додаткові позначення. І для циклів, і для умов використовуються фрейми взаємодій (inter action frames), що представляють собою засіб розмітки діаграми взаємодії.

Як застосовувати техніку креативності

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

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

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

Іншим корисним видом діаграм взаємодій є комунікаційні діаграми , Які показують з'єднання, і тимчасові діаграми, що показують тимчасові інтервали.

CRC-картки

Одним з найбільш корисних прийомів, відповідних хорошого стилю ООП, є дослідження взаємодії об'єктів, оскільки його мета полягає в тому, щоб досліджувати роботу програми, а не дані. CRC-діаграми (Class-Responsibility-Collaboration, клас-обов'язок-кооперація), придумані Уордом Каннінгемом (Ward Cunningham) в кінці 80-х років, витримали перевірку часом і стали високоефективним інструментом вирішення цього завдання (рис. 4.6). І хоча вони не входять до складу UML, все ж є дуже популярними серед висококваліфікованих розробників в області об'єктних технологій.

Для використання CRC-карток ви і ваші колеги повинні зібратися за столом. Візьміть різні сценарії і програйте їх за допомогою карток, піднімаючи їх над столом, в той час коли вони активні, і передаючи їх по колу в припущенні, що вони посилають повідомлення. Цю технологію майже неможливо описати в книзі, але легко продемонструвати; кращий спосіб навчитися цьому полягає в тому, щоб попросити кого-небудь, хто має такий досвід, показати вам це

Важливим моментом в CRC-методикою є визначення відповідальностей. Відповідальність (responsibility) - це короткий опис того, що об'єкт повинен робити: операція, яку виконує об'єкт, певний обсяг знань, який об'єкт підтримує, або будь-які важливі рішення, що приймаються об'єктом. Ідея полягає в тому, щоб ви могли взяти будь-який клас і сформулювати його розумно обмежені обов'язки. Такий образ дії допоможе вам чіткіше уявити собі архітектуру класів.

Друга літера «С» (в CRC) означає взаємодію (collaboration): інші класи, з якими повинен працювати розглянутий клас. Це дає вам деяке уявлення про зв'язки між класами, але все ще на високому рівні.

Одне з головних переваг CRC-карток полягає в тому, що вони сприяють живому обговоренню проектів в середовищі розробників. Якщо в процесі роботи над шаблоном поведінки ви хочете подивитися, як класи його реалізують, то креслення діаграм взаємодії, описаних в цьому розділі, може зайняти занадто багато часу. Звичайно потрібно переглянути варіанти, а малювання і стирання варіантів на діаграмах може бути дуже виснажливим. За допомогою CRC-карток розробники моделюють взаємодію, піднімаючи картки і передаючи їх по колу. Це дозволяє швидко прорахувати варіанти.

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

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

Багато розробники підкреслюють важливість рольової гри, коли кожен член команди грає роль одного або декількох класів.

як навчитися

Тут ми спробували надати якомога простіший спосіб вивчення діаграми послідовності мови UML.

Як і багато інших мов він використовує для опису набір знаків. Сенс цих знаків ви знайдете в таблиці в розділі «Зауваження (опис)». Кожен знак має своє найменування (термін) і написання. Також кожен термін забезпечений коротким поясненням, щоб швидко усвідомити його основну суть.

Далі ми б рекомендували перейти в розділ «Приклад», щоб спробувати свої сили в читанні різних діаграм. Потім варто вивчити розділ «Застосування», так як, хоча і кількість типів діаграм в UML невелика, максимум переваг від їх використання ви зможете отримати тільки якщо будете застосовувати потрібні діаграми за призначенням.

приклад використання

Для того щоб почати обговорення методу «Діаграма послідовності» UML (ЮМЛ), розглянемо простий сценарій.

Припустимо, що у нас є замовлення, і ми збираємося викликати команду для визначення його вартості. При цьому об'єкту замовлення (Order) необ ходимо переглянути всі позиції замовлення (Line Items) і визначити їх ціни, засновані на правилах побудови ціни продукції в рядку замовлення (Order Line). Проробивши це для всіх позицій замовлення, об'єкт за каза повинен обчислити загальну знижку, яка визначається індиві дуально для кожного клієнта.
На рис. 4.1 приведена діаграма, що представляє реалізацію дан ного сценарію. Діаграми послідовності показують взаємо дію, представляючи кожного учасника разом з його лінією життя (lifeline), яка йде вертикально вниз і впорядковує повідомлення на сторінці; повідомлення також слід читати зверху вниз.

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

Однак діаграма не всі показує так добре. Послідовність повідомлень getQuantity, getProduct, getPricingDetails і calculateBasePrice повинна бути реалізована для кожного рядка замовлення, тоді як метод calculateDiscounts викликається лише одного разу.

На наведеній діаграмі іменували учасників, використовуючи стиль anOrder. У більшості випадків це цілком прийнятно. Ось більш повний синтаксис: ім'я: Клас, де і ім'я, і клас не обов'язкові, але якщо клас використовується, то двокрапка має бути присутнім.

Кожна лінія життя має смугу активності, яка показує інтервал активності учасника при взаємодії. Вона відповідає часу знаходження в стеці одного з методів учасника. У мові UML смуги активності не обов'язкові.

У першого повідомлення немає учасника, Хто послав Мене, оскільки воно приходить з невідомого джерела. Воно називається знайденим зі спілкуванням (found message).

Створення та видалення учасників

У діаграмах послідовності для створення і видалення учасників застосовуються деякі додаткові позначення (рис. 4.3).

У разі створення учасника треба намалювати стрілку повідомлення, спрямовану до прямокутника учасника. Якщо застосовується конструктор, то ім'я повідомлення не обов'язково, але зазвичай маркуємо його словом «new» в будь-якому випадку. Якщо учасник виконує що-небудь безпосередньо після створення, наприклад команду запиту, то треба
почати активацію відразу після прямокутника учасника.

Видалення учасника позначається великим хрестом (X). Стрілка повідомлення, що йде в X, означає, що один учасник явно видаляє іншого; X в кінці лінії життя показує, що учасник видаляє сам себе.

Діаграма послідовності: цикли, умови тощо

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

Як було сказано, існують додаткові позначення. І для циклів, і для умов використовуються фрейми взаємодій (inter action frames), що представляють собою засіб розмітки діаграми взаємодії. На рис. 4.4 показаний простий алгоритм, заснований на наступному псевдокоді.
foreach (lineitem)
if (product.value> $ 10K)
careful.dispatch
else
regular.dispatch
end if
end for
if (needsConfirmation) messenger.confirm
end procedure

В основному фрейми складаються з деякої області діаграми послідовності, розділеної на кілька фрагментів. Кожен фрейм має оператор, а кожен фрагмент може мати захист. (В табл. 4.1 перераховані загальноприйняті оператори для фреймів взаємодії.)

Для відображення циклу застосовується оператор loop з єдиним фрагментом, а тіло ітерації поміщається в захист. Для умовної логіки можна використовувати оператор alt і поміщати умова в кожен фрагмент. Буде виконано тільки той фрагмент, захист якого має справжнє значення. Для єдиною області існує оператор opt.

Якщо вам сподобалася стаття - поділіться посиланням з друзями!