|
|||||||
АвтоАвтоматизацияАрхитектураАстрономияАудитБиологияБухгалтерияВоенное делоГенетикаГеографияГеологияГосударствоДомДругоеЖурналистика и СМИИзобретательствоИностранные языкиИнформатикаИскусствоИсторияКомпьютерыКулинарияКультураЛексикологияЛитератураЛогикаМаркетингМатематикаМашиностроениеМедицинаМенеджментМеталлы и СваркаМеханикаМузыкаНаселениеОбразованиеОхрана безопасности жизниОхрана ТрудаПедагогикаПолитикаПравоПриборостроениеПрограммированиеПроизводствоПромышленностьПсихологияРадиоРегилияСвязьСоциологияСпортСтандартизацияСтроительствоТехнологииТорговляТуризмФизикаФизиологияФилософияФинансыХимияХозяйствоЦеннообразованиеЧерчениеЭкологияЭконометрикаЭкономикаЭлектроникаЮриспунденкция |
Примітка. Доповнити діаграму послідовності для цього прикладу тимчасовими обмеженнями пропонується виконати самостійно
Доповнити діаграму послідовності для цього прикладу тимчасовими обмеженнями пропонується виконати самостійно. 22.4. Рекомендації з побудови діаграм послідовності Як ми вже відзначали, побудову діаграми послідовності доцільно починати з виділення із всієї сукупності тих і тільки тих класів, об'єкти яких беруть участь у модельованій взаємодії. Після цього всі об'єкти наносяться на діаграму з дотриманням деякого порядку ініціалізації повідомлень. Тут необхідно встановити, які об'єкти будуть існувати постійно, а які тимчасово – тільки на період виконання ними необхідних дій. Рис. 22.10. Остаточний варіант діаграми послідовності для моделювання телефонної розмови Коли об'єкти візуальовані, можна приступати до специфікації повідомлень. При цьому варто враховувати ті ролі, які відіграють повідомлення в системі. При необхідності для уточнення цих ролей треба використати їхні різновиди й стереотипи. Для знищення об'єктів, які створюються на час виконання своїх дій, потрібно передбачити явне повідомлення. Найпростіші випадки розгалуження процесу взаємодії можна зобразити на одній діаграмі з використанням відповідних графічних примітивів. Однак варто пам'ятати, що кожний альтернативний потік керування може істотно ускладнити розуміння побудованої моделі. Тому загальним правилом є візуалізація кожного потоку керування на окремій діаграмі послідовності. У цій ситуації такі окремі діаграми повинні розглядатися спільно як одна модель взаємодії. Подальша деталізація діаграми послідовності пов'язана із введенням тимчасових обмежень до виконання окремих дій у системі. Для простих асинхронних повідомлень тимчасові обмеження можуть бути відсутні. Однак необхідність синхронізувати складні потоки керування, як правило, вимагає введення в модель таких обмежень. Загальний їхній запис повинен дотримуватися семантики мови об'єктних обмежень. Висновки Контрольні питання 1. Призначення діаграми послідовності. 2. Лінія життя об'єкта. 3. Фокус керування. 4. Повідомлення між об'єктами на діаграмі послідовності. 5. Розгалуження потоку керування. 6. Стереотипи повідомлень. 7. Тимчасові обмеження на діаграмах послідовності. 8. Наведіть приклад побудови діаграми послідовності. РОЗДІЛ 23. Діаграма кооперації (collaboration diagram) à Кооперація à Мультиоб'єкт. Активний об'єкт. Складений об'єкт à Зв'язки. Стереотипи зв'язків à Рекомендації з побудови діаграм кооперації
Як наголошувалося у попередньому розділі, особливості взаємодії елементів модельованої системи можуть бути подані на діаграмах послідовності і кооперації. Якщо перша служить для візуалізації тимчасових аспектів взаємодії, то діаграма кооперації призначена для специфікації структурних аспектів взаємодії. Головна особливість діаграми кооперації полягає в можливості графічно представити не тільки послідовність взаємодії, але і всі структурні відношення між об'єктами, що беруть участь в цій взаємодії. Перш за все, на діаграмі кооперації у вигляді прямокутників зображаються об'єкти, що беруть участь у взаємодії, містять ім'я об'єкту, його клас і, можливо, значення атрибутів. Далі, як і на діаграмі класів, вказуються асоціації між об'єктами у вигляді різних з’єднювальних ліній. При цьому можна явно вказати імена асоціації і ролей, які відіграють об'єкти в цій асоціації. Додатково можуть бути зображені динамічні зв'язки – потоки повідомлень. Вони представляються також у вигляді з’єднювальних ліній між об'єктами, над якими розташовується стрілка з вказівкою напряму, імені повідомлення і порядкового номера в загальній послідовності ініціалізації повідомлень. На відміну від діаграми послідовності, на діаграмі кооперації зображаються тільки відношення між об'єктами, що відіграють певні ролі у взаємодії. З іншої сторони, на цій діаграмі не вказується час у вигляді окремого виміру. Тому послідовність взаємодій і паралельних потоків може бути визначена за допомогою порядкових номерів. Отже, якщо необхідно явно специфікувати взаємозв'язки між об'єктами в реальному часі, краще це робити на діаграмі послідовності. Поведінка системи може описуватися на рівні окремих об'єктів, які обмінюються між собою повідомленнями, щоб досягти потрібної мети або реалізувати деякий сервіс. З погляду аналітика або конструктора важливо представити в проекті системи структурні зв'язки окремих об'єктів між собою. Таке статичне представлення структури системи як сукупності взаємодіючих об'єктів забезпечує діаграма кооперації. Таким чином, за допомогою діаграми кооперації можна описати повний контекст взаємодій як своєрідний часовий "зріз" сукупності об'єктів, що взаємодіють між собою для виконання певного завдання або бізнес-мети програмної системи. 23.1. Кооперація Поняття кооперації (collaboration) є одним з фундаментальних понять в мові UML. Воно служить для позначення множини об'єктів, що взаємодіють з певною метою, в загальному контексті модельованої системи. Мета самої кооперації полягає в тому, щоб специфікувати особливості реалізації окремих найзначущих операцій в системі. Кооперація визначає структуру поведінки системи в термінах взаємодії учасників цієї кооперації. Кооперація може бути подана на двох рівнях: ¨ На рівні специфікації – вказує ролі класифікаторів і ролі асоціацій в цій взаємодії. ¨ На рівні прикладів – вказує екземпляри і зв'язки, створюючи окремі ролі в кооперації. Діаграма кооперації рівня специфікації вказує ролі, які відіграють елементи, що беруть участь у взаємодії. Елементами кооперації на цьому рівні є класи і асоціації, які позначають окремі ролі класифікаторів і асоціації між учасниками кооперації. Діаграма кооперації рівня прикладів представляється сукупністю об'єктів (екземпляри класів) і зв'язків (екземпляри асоціацій). При цьому зв'язки доповнюються стрілками повідомлень. На даному рівні вказуються тільки релевантні об'єкти, тобто що мають безпосереднє відношення до реалізації операції або класифікатора. У кооперації рівня прикладів визначаються властивості, які повинні мати екземпляри для того, щоб брати участь в кооперації. Окрім властивостей об'єктів на діаграмі кооперації також вказуються асоціації, які повинні мати місце між об'єктами кооперації. При цьому зовсім не обов'язково зображати всі властивості або всі асоціації, оскільки на діаграмі кооперації присутні тільки ролі класифікаторів, а не самі класифікатори. Таким чином, тоді як класифікатор вимагає повного опису всіх своїх екземплярів, роль класифікатора вимагає опису тільки тих властивостей і асоціацій, які необхідні для участі в окремій кооперації. Звідси випливає важливий наслідок. Одна і та ж сукупність об'єктів може брати участь в різних коопераціях. При цьому, залежно від кооперації, можуть змінюватися як властивості окремих об'єктів, так і зв'язки між ними. Саме це відрізняє діаграму кооперації від діаграми класів, на якій повинні бути вказані всі властивості і асоціації між елементами діаграми. Поиск по сайту: |
Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Студалл.Орг (0.003 сек.) |