Зміст і нотація цієї діаграми повністю збігаються з тими, що використовуються в методі І. Джекобсона (див. п. 3.5.1.).
5.4 Діаграми моделювання поведінки системи
Поведінка системи розглядається як обмін повідомленнями між об’єктами для досягнення певної мети. Різні сторони взаємодії об’єктів відображаються у різних діаграмах:
- діаграми послідовності демонструють впорядкованість взаємодії (тобто, обмін повідомленнями) в часі (уподовж лінії життя об’єктів);
- діаграми співробітництва демонструють ролі, які відіграють об’єкти під час взаємодії для досягнення певних цілей;
- діаграми активності демонструють потоки керування при взаємодії об’єктів;
- діаграми станів демонструють динаміку зміни станів об’єктів під впливом перебігу подій (аналогічно до діаграм переходів у стани, про які йшла мова у п. 3.4.3.).
Для наочного подання поведінки об’єктів у сценаріях застосовується спеціальна нотація, так звана діаграма взаємодії. Для її побудови кожному з об’єктів сценарію ставиться у відповідність його лінія життя, яка відображає перебіг подій між його створенням та руйнуванням. На діаграмі вона позначається вертикальною пунктирною лінією, на верхівці якої в прямокутнику зображається назва об’єкта. Діаграма являє собою всі об’єкти, які беруть участь у взаємодії. Крайня права лінія зображає зовнішнє середовище, з яким взаємодіє сценарій, тобто його зовнішній інтерфейс (зокрема це може бути інтерфейс з актором). Допускається кілька зовнішніх інтерфейсів для одного сценарію.
Порядок сусідства об’єктів не має принципового значення і обирається довільно, з намаганням забезпечити наочність взаємодії.
Вертикальний вимір діаграми відповідає осі часу, плин часу вважається вподовж осі зверху донизу і має відносний характер: відстань на осі часу не має відповідності інтервалу реального часу, розташування вподовж осі часу показує лише послідовність подій.
Ліворуч від осі зовнішнього інтерфейсу може наводитися перелік дій, які відбуваються в сценарії за відповідний період часу.
Ініційовані екземпляри об’єктів, поведінка яких забезпечує зазначені дії, зображаються на відповідних лініях життя подовженими прямокутниками. Довжина прямокутника відповідає інтервалу активності екземпляра об’єкта (тобто часу виконання його операцій). Отже, діаграма послідовності відображає потоки керування.
Якщо екземпляр об’єкта існував до старту діаграми, перша стрілка, яка веде до об’єкта, проводиться нижче верхівки його лінії життя.
Якщо об’єкт створюється в певний момент часу, стрілка, яка відповідає повідомленню про його створення, спрямовується до верхівки його лінії життя.
Якщо екземпляр об’єкта руйнується, нижня межа його лінії життя позначається перехрестям як символом руйнування.
Лінії життя можуть розгалужуватися, що демонструє умовні варіації поведінки об’єкта, або зливатися.
Приклад діаграми послідовності наведено на рис. 5.11.
Як уже було сказано, взаємодія об’єктів контролюється подіями, які відбуваються в сценарії і які стимулюють об’єкти для посилання одне одному повідомлень. Повідомлення позначаються на діаграмі стрілками, над якими можуть вказуватися зміст повідомлення, параметри, які воно передає та порядковий номер повідомлення в сценарії. Зазначимо, що вказані на діаграмі повідомлення мають узгоджуватися з видимими операціями відповідних класів.
У наведеному прикладі екземпляри об’єктів 1, 2, 4 були до запуску сценарію і залишилися після його закінчення. Екземпляр об’єкта 3 було створено в сценарії і після виконання певних операцій зруйновано.
Діаграми співробітництва являють собою сукупність об’єктів, поведінка яких значуща для досягнення складових мети системи, та взаємовідношення тих ролей, які об’єкти відіграють у співробітництві. На даному вигляді діаграм моделюється статична взаємодія об’єктів, при цьому фактор часу не враховується і не відображається на діаграмі співробітництва.
Рисунок 5.11 - Приклад діаграми послідовності
Діаграма співробітництва може бути параметризованою. Тоді вона являє собою абстрактну схему співробітництва - так званий патерн, для якого шляхом до визначення параметрів можна створити певну множину конкретних схем співробітництва. Докладніше патерни обговорюються в розділі 7 (див. п. 7.3.7.).
Модель діяльності в UML являє собою поведінку системи як певні роботи, котрі можуть виконувати як система, так і актор, причому послідовність робіт може залежати від прийняття певних рішень залежно від умов, що склалися. Окрема діяльність (робота) зображається на діаграмі прямокутником із закругленими кутами. Потоки керування між роботами показуються стрілками. Якщо мова йде про прийняття рішення, то з відповідного прямокутника виходять дві стрілки, на кожній може позначатися текст умови, якій вона відповідає. Діаграма діяльності нагадує відомі блок-схеми алгоритмів та програм, зокрема передбачено відображення можливості виконувати паралельно кілька діяльностей і точки синхронізації завершення їх. Приклад. Нехай пошук замовленої книги в бібліотеці має супроводжуватися кількома супутніми процедурами, а саме збиранням даних про виконані та невиконані замовлення. Другі при цьому поділяються на невиконані через те, що в бібліотеці немає книг та через те, що вони в інших читачів. На рис. 5.12. подано відповідну діаграму діяльностей. Горизонтальні лінії позначають розпаралелення та синхронізацію окремих робіт.
Рисунок 5.12 - Діаграма діяльностей сценарію замовлення книг у бібліотеці
Діаграма може відображати той факт, що певна діяльність виконується для кожного існуючого екземпляра об’єкта, наприклад, для кожного рядка замовлення (якщо, наприклад, замовляється кілька книжок одразу). Тоді стрілка, яка веде до такої діяльності, позначається зірочкою, як на рис. 5.13.
Як і діаграма переходів у стани (див. п. 3.4.2.), модель станів UML базується на використанні розширеної моделі скінченного автомата. Нею визначаються:
- умови переходів (застереження - guards on transitions)
- переходи, зумовлені певними подіями;
- дії при переході;
- дії при вході в стан;
- діяльність, яка триває доти, доки стан є активним;
- дії при виході зі стану;
- вставка станів;
- паралельно діючі стани.
Рисунок 5.13 - Фрагмент діаграми діяльності для кожної замовленої книги
Можуть виділятися суперстани та підстани. Вони разом із вкладеними станами дозволяють конструювати ієрархію станів системи. У даному разі подія - це назва переходу. Події можуть мати аргументи, які визначають список даних, що передаються з переходом (такі, як помилка коду або моніторинг значення). Застереження визначає умови, які потрібно виконати для здійснення переходу. Нарешті список операцій визначає деякий список функцій разом з їхніми аргументами, котрі буде викликано як результат цього переходу.
5.9.1 Діаграми компонент
Призначенням діаграми компонент є відображення структур системи як композиції компонент і зв’язків між ними так, як їх уявляє собі програміст. Це граф, вузлами якого є компоненти, а дуги відображають відношення залежності. Серед видів компонент особливого обговорення заслуговує пакет (див. п. 5.10).
5.9.2 Діаграми розміщення
Призначенням даної діаграми є визначення складу фізичних ресурсів системи (що позначаються як вузли системи) та відношень між ними. Системи реального часу в багатьох випадках базуються на різних платформах замовника. Інженер повинен розробити не лише програмну частину, а й визначити необхідні апаратні пристрої. Ці пристрої мають органічно взаємодіяти з програмними компонентами. Іконка програмної компоненти зображається як прямокутник з двома невеличкими прямокутниками, вузол обладнання - як прямокутник зі спеціальною рамкою. На рис. 5.14 показано розміщення компонент на вузлах системи.
Для діаграми зазвичай використовуються фіксовані стереотипи: <<процесор>>, <<пристрій>>, <<дисплей>>, <<пам’ять>>, <<диск>> тощо.
Вінницький національний технічний університет