- •1.1. Методологія процедурно‑ орієнтованого програмування
- •1.2. Методологія об'єктно-орієнтованого програмування
- •1.3. Методологія об'єктно-орієнтованого аналізу і проектування
- •1.4. Методологія системного аналізу і системного моделювання
- •Розділ 2
- •2.1. Передісторія. Математичні основи
- •Мал. 2.4. Приклади неорієнтованого (а) і орієнтованого (б) графів
- •Мал. 2.5. Приклади неорієнтованого (а) і орієнтованого (б) дерев
- •Мал. 2.6. Ієрархічні схеми неорієнтованого дерева (а) і орієнтованого дерева (б)
- •2.2. Діаграми структурного системного аналізу
- •I (Input) – вхід, т. Е. Все, що поступає в процес або споживається процесом.
- •2.3. Основні етапи розвитку uml
- •2. Забезпечити початкові поняття язика uml можливістю розширення і спеціалізації для більш точного представлення моделей систем в конкретній наочній області.
- •3. Опис язика uml повинен підтримувати таку специфікацію моделей, яка не залежить від конкретних язиків програмування і інструментальних засобів проектування програмних систем.
- •4. Опис язика uml повинен включати семантичний базис для розуміння загальних особливостей ооап.
- •7. Інтегрувати в себе новітні і якнайкращі досягнення практики ооап.
- •3.2. Загальна структура язика uml
- •3.3. Пакети в язиці uml
- •3.4. Основні пакети метамоделі язика uml
- •3.5. Специфіка опису метамоделі язика uml
- •3.6. Особливості зображення діаграм язика uml
- •4.1. Варіант використовування
- •4.2. Актори
- •4.3. Інтерфейси
- •4.4. Примітки
- •4.5. Відносини на діаграмі варіантів використовування
- •4.6. Приклад побудови діаграми варіантів використовування
- •4.7. Рекомендації по розробці діаграм варіантів використовування
- •5.1. Клас
- •5.2. Відносини між класами
- •5.5. Шаблони або класи, що параметризуються
- •5.6. Рекомендації по побудові діаграм класів
- •6.1. Автомати
- •Include – ця мітка використовується для звернення до підавтомата, при цьому наступний за нею вираз дії містить ім'я цього підавтомата.
- •6.3. Перехід
- •6.4. Складовий стан і підстан
- •6.5. Історичний стан
- •Мал. 6.10. Графічне зображення недавнього (а) і давнього (б) історичного стану
- •6.6. Складні переходи
- •Мал. 6.11. Графічне зображення паралельного переходу з паралельних станів (а) і паралельного переходу в паралельні стани (б)
- •6.7. Заключні рекомендації по побудові діаграм станів
- •7.1. Стан дії
- •7.2. Переходи
- •7.5. Рекомендації по побудові діаграм діяльності
- •8.2. Повідомлення
- •Мал. 8.7. Діаграма послідовності із стереотипними значеннями повідомлень
- •8.3. Приклад побудови діаграми послідовності
- •8.4. Заключні рекомендації по побудові діаграм послідовності
- •9.1. Кооперація
- •9.3. Зв'язки
- •9.4. Повідомлення
- •9.6. Заключні рекомендації по побудові діаграм кооперації
- •10.1. Компоненти
- •10.2. Інтерфейси
- •10.3. Залежність
- •10.4. Рекомендації по побудові діаграми компонентів
- •11.1. Вузол
- •11.2. З'єднання
- •Мал. 11.4. Фрагмент діаграми розгортання із з'єднаннями меходу вузлами
- •11.3. Рекомендації по побудові діаграми розгортання
- •12.1. Загальна характеристика case‑ засобу Rational Rose 98/2000
- •12.2. Особливості робочого інтерфейсу Rational Rose
- •12.3. Початок роботи над проектом в середовищі Rational Rose
- •12.4. Розробка діаграми варіантів використовування в середовищі Rational Rose
- •12.5. Розробка діаграми класів в середовищі Rational Rose
- •12.6. Розробка діаграми станів в середовищі Rational Rose
- •12.7. Розробка діаграми послідовності в середовищі Rational Rose
- •12.8. Розробка діаграми кооперації в середовищі Rational Rose
- •12.9. Розробка діаграми компонентів в середовищі Rational Rose
- •12.10. Розробка діаграми розгортання в середовищі Rational Rose
8.4. Заключні рекомендації по побудові діаграм послідовності
Як вже наголошувалося, побудову діаграми послідовності доцільно починати з виділення зі всієї сукупності тих і лише тих класів, об'єкти яких беруть участь в модельованій взаємодії. Після цього всі об'єкти наносяться на діаграму з дотриманням деякого порядку ініціалізації повідомлень. Тут необхідно встановити, які об'єкти існуватимуть постійно, а які тимчасово – тільки на період виконання ними необхідних дій.
Коли об'єкти візуалізовані, можна приступати до специфікації повідомлень. При цьому слід враховувати ті ролі, які грають повідомлення в системі. При необхідності уточнення цих ролей треба використовувати їх різновиди і стереотипи. Для знищення об'єктів, які створюються на час виконання своїх дій, потрібно передбачити явне повідомлення.
Найпростіші випадки галуження процесу взаємодії можна зобразити на одній діаграмі з використанням відповідних графічних примітивів. Проте слід пям'ятати, що кожний альтернативний потік управління може істотно утрудняти розуміння побудованої моделі. Тому загальним правилом є візуалізація кожного потоку управління на окремій діаграмі послідовності. В цій ситуації такі окремі діаграми повинні розглядатися спільно як одна модель взаємодії.
Подальша деталізація діаграми послідовності пов'язана з введенням тимчасових обмежень на виконання окремих дій в системі. Для простих асинхронних повідомлень тимчасові обмеження можуть бути відсутні. Проте необхідність синхронізувати складні потоки управління, як правило, вимагають введення в модель таких обмежень. Загальний їх запис повинен слідувати семантиці язика об'єктних обмежень, який розглянутий в додатку.
РОЗДІЛ 9
Діаграма кооперації (collaboration diagram)
Як наголошувалося в попередньому розділі, особливості взаємодії елементів модельованої системи можуть бути представлені на діаграмах послідовності і кооперації. Якщо перша служить для візуалізації тимчасових аспектів взаємодії, то діаграма кооперації призначена для специфікації структурних аспектів взаємодії. Головна особливість діаграми кооперації полягає в можливості графічно представити не тільки послідовність взаємодії, але і всі структурні відносини між об'єктами, що беруть участь в цій взаємодії.
Перш за все, на діаграмі кооперації у вигляді прямокутників зображаються беруть участь у взаємодії об'єкти, що містять ім'я об'єкту, його клас і, можливо, значення атрибутів. Далі, як і на діаграмі класів, указуються асоціації між об'єктами у вигляді різних сполучних ліній. При цьому можна явно вказати імена асоціації і ролей, які грають об'єкти в даній асоціації. Додатково можуть бути зображені динамічні зв'язки – потоки повідомлень. Вони представляються також у вигляді сполучних ліній між об'єктами, над якими розташовується стрілка з вказівкою напряму, імені повідомлення і порядкового номера в загальній послідовності ініціалізації повідомлень.
На відміну від діаграми послідовності, на діаграмі кооперації зображаються тільки відносини між об'єктами, що грають певні ролі у взаємодії. З другого боку, на цій діаграмі не указується час у вигляді окремого вимірювання. Тому послідовність взаємодій і паралельних потоків може бути визначена за допомогою порядкових номерів. Отже, якщо необхідно явно специфікувати взаємозв'язки між об'єктами в реальному часі, краще це робити на діаграмі послідовності.
Поведінка системи може описуватися на рівні окремих об'єктів, які обмінюються між собою повідомленнями, щоб досягти потрібної мети або реалізувати деякий сервіс. З погляду аналітика або конструктора важливо представити в проекті системи структурні зв'язки окремих об'єктів між собою. Таке статичне представлення структури системи як сукупності взаємодіючих об'єктів і забезпечує діаграма кооперації.
Таким чином, за допомогою діаграми кооперації можна описати повний контекст взаємодій як своєрідний часовий «зрізу» сукупності об'єктів, що взаємодіють між собою для виконання певної задачі або бизнес‑ цели програмної системи.
