12.3. Завдання
1. Вибрати в системі, що моделюється, варіант використання, для якого будуть будуватися діаграми взаємодії.
2. Побудувати для обраного варіанта використання діаграму послідовності.
3. Побудувати для того ж варіанта використання діаграму кооперації.
4. Сформулювати достоїнства і недоліки кожного виду діаграм при моделюванні даного варіанта використання.
12.4. Контрольнізапитання
Для чого призначені діаграми взаємодії?
Назвіть два види діаграми взаємодії. У чому складається їхнє розходження ?
Яке призначення лінії життя на діаграмі послідовності?
Як позначаються об'єкти на діаграмі послідовності? Як вони розташовуються на діаграмі?
Як на діаграмі послідовності представляються повідомлення?
Що таке самоделегування?
Що показує активізація об'єкта?
13. Представлення реалізації
Мова UML може використовуватися для відображення стратегічних рішень у системі. Представлення реалізації визначає реальну організацію програмних модулів у середовищі розробки. Воно враховує потреби в простоті розробки, керуванні програмними засобами, повторному використанні коду, а також язикових і інструментальних обмеженнях. Елементами моделювання в представленні компонентів (component vіew) є пакети, компоненти і зв'язки між ними.
13.1. Діаграми пакетів
Об’єктно-орієнтований підхід до проектування припускає угруповання класів у компоненти більш високого рівня. У UML такий механізм угруповання має назву пакетів. Пакети в даному представленні архітектури - це фізичний розділ системи. Пакети організовані у виді ієрархії рівнів або шарів, де кожен рівень має чітко визначений інтерфейс. На рис.13.1 зображена типова схема рівнів системи.
|
Інтерфейс користувача |
|
Пакети, пов’язані з додатками |
|
Бізнес-пакети |
|
Ключові механізмі |
|
Пакети апаратних засобів та операційної системи |
Рис. 13.1. Рівні системи.
До діаграми пакетів входять пакети класів і залежності між ними. Можна сказати, що діаграми пакетів - це форма діаграми класів, але на практиці причини побудови цих діаграм різні.
Залежність між двома пакетами існує в тому випадку, якщо зміни у визначенні одного елемента можуть викликати зміни в іншому. Що стосується класів, то причини залежностей можуть бути самими різними: один клас посилає повідомлення іншому; один клас посилається на іншій як на параметр операції. Якщо клас змінює свій інтерфейс, то будь-яке повідомлення, що він посилає, може стати неправильним. При проектуванні великих систем намагаються мінімізувати залежності між класами.
Пакети не дають відповіді на питання, яким образом можна зменшити кількість залежностей у розроблювальній системі, однак вони допомагають виділити ці залежності.
Пакети дозволяють полегшити розглядання діаграми класів великих проектів.
Нотація мови UML для зображення пакетів у представленні компонентів нагадує зображення пакетів у логічному представленні (рис. 13.2).
Рис. 13.2. Приклад діаграми пакетів.
На цій діаграмі класи предметної області, що моделюють діяльність торговельної фірми, згруповані в два пакети - Замовлення і Клієнти. Додаток Збір замовлень зв'язаний залежностями з цими двома пакетами предметної області. Користувальницький інтерфейс має залежності з Графічною бібліотекою і Додатком збору замовлень.