Патерн Компоновщик (Composite) забезпечує подання ієрархій частина-ціле, об'єднуючи об'єкти в деревовидні структури.
Проблема. Дуже часто виникає необхідність створювати маленькі компоненти (примітиви), об'єднувати їх в більш великі компоненти (контейнери), більші компоненти з'єднувати в великі компоненти, великі компоненти - в величезні і т. Д. При цьому клієнтам доводиться розрізняти компоненти-примітиви і компоненти- контейнери, працювати з ними по-різному. Це ускладнює додаток. Патерн Компоновщик дозволяє ліквідувати цю відмінність, його можна застосовувати в наступних випадках:
q необхідно побудувати ієрархію об'єктів виду частина-ціле;
q потрібно уніфікувати використання як складових, так і індивідуальних об'єктів.
Рішення. Ключовим елементом рішення є абстрактний клас Компонент, який є одночасно і примітивом, і контейнером. У ньому оголошені:
q абстрактна операція примітиву Працювати ();
q абстрактні операції контейнера - управління примітивами-нащадками Додати (Компонент) і Видалити (Компонент), а також доступу до нащадка Отримати-Нащадка ().
Структурна складова паттерна Компоновщик представлена на рис. 12.51.
Мал. 12.51. Структурна складова паттерна Компоновщик
З малюнка видно, що за допомогою паттерна організовується рекурсивна композиція.
Клас Компонент служить простим елементом дерева, клас Компоновщик є рекурсивним елементом, а клас Лист - кінцевим елементом дерева. Клас Компонент служить батьком класів Лист і Компоновщик. Відзначимо, що клас Компоновщик є агрегатом складових частин - екземплярів класу Компонент (таким чином задається рекурсія).
Клієнти використовують інтерфейс класу Компонент для взаємодії з об'єктами дерева. Якщо одержувачем запиту клієнта є об'єкт-лист, то він і обробляє запит. Якщо ж одержувачем є складовою об'єкт-компонувальник, то він перенаправляє запит своїм нащадкам, можливо виконуючи додаткові дії до або після перенаправлення.
Позначення паттерна Компоновщик наведено на рис. 12.52, де показано, що у нього три параметра настройки - компонент, компонувальник і лист.
Налаштування патерну на графічне додаток ілюструє рис. 12.53.
Мал. 12.52. Позначення паттерна Компоновщик
Мал. 12.53. Налаштування паттерна Компоновщик
У цьому випадку основною операцією додатки стає операція Малювати (). Мається на увазі, що така операція входить до складу кожного з класів, що підключаються, тобто класів Малюнок, Прямокутник і Графічний елемент. Операції Малювати () повинні замістити операції Працювати () в класах патерну.
Патерн Команда (Command) виконує перетворення запиту в об'єкт, забезпечуючи:
q параметризацію клієнтів з різними запитами;
q постановку запитів в чергу і їх реєстрацію;
q підтримку скасування операцій.
Проблема. Досить часто потрібно надсилати запит, не знаючи, виконання якої конкретної операції запрошено і хто є одержувачем запиту. У цих випадках слід відокремити об'єкт, який ініціює запит, від об'єкта, здатного виконати запит. В результаті забезпечується висока гнучкість розробки призначеного для користувача інтерфейсу - можна пов'язувати різні пункти меню з певною функцією, динамічно підміняти команди і т. Д. Патерн Команда застосовується в наступних випадках:
q об'єкти параметрізіруются дією. У процедурних мовах параметризация здійснюється за допомогою функції зворотного виклику, яка реєструється для подальшого виклику. Патерн Команда пропонує об'єктно-орієнтовану заміну функцій зворотного виклику;
q необхідно забезпечити скасування операцій. Це можливо завдяки зберіганню історії виконання операцій;
q необхідно реєструвати зміни стану для відновлення системи в разі аварійного відмови;
q необхідне створення складних операцій, які будуються на основі примітивних операцій.
Рішення. Основним елементом рішення є абстрактний клас Команда, що забезпечує одну абстрактну операцію Виконувати (). Конкретні підкласи цього класу реалізують операцію Виконувати (). Вони задають пару одержувач-дію. Одержувач запам'ятовується в екземплярність змінної підкласу. Запит одержувачу надсилається в ході виконання конкретної операції Виконувати ().
Структурна складова паттерна Команда показана на рис. 12.54. Класи цієї структури мають такі обов'язки:
q Команда оголошує інтерфейс для виконання операції;
q КонкрКоманда визначає зв'язок між екземпляром класу Одержувач і дією, реалізує Виконувати (), викликаючи потрібну операцію одержувача;
q Клієнт створює об'єкт класу КонкрКоманда і встановлює його одержувача;
q Ініціатор просить команду виконати запит;
q Одержувач вміє виконувати запитувані операції.
Мал. 12.54. Структурна складова паттерна Команда
Як конкретної команди можуть виступати команда Відкрити, команда Вставити. Ініціатором може бути Пункт Меню, а одержувачем - Документ.
Об'єкти цього патерну здійснюють такі взаємодії:
q клієнт створює об'єкт класу КонкрКоманда і задає його одержувача;
q об'єкт класу Ініціатор зберігає об'єкт класу КонкрКоманда;
q ініціатор викликає операцію Виконувати () об'єкта класу КонкрКоманда;
q об'єкт класу КонкрКоманда викликає операцію свого одержувача для виконання запиту.
Результати. Застосування патерну Команда призводить до наступного:
q об'єкт, запитувач операцію, відділяється від об'єкта, який вміє виконувати запит;
q об'єкти-команди є повноцінними об'єктами. Їх можна використовувати і розширювати звичайним способом;
q з простих команд легко компонуються складові команди;
q легко додаються нові команди (змінювати існуючі класи при цьому не потрібно).
Позначення паттерна Команда наведено на рис. 12.55, де показано, що у нього чотири параметри налаштування - клієнт, команда, ініціатор і одержувач.
Мал. 12.55. Позначення паттерна Команда
Налаштування патерну на додаток з графічним меню ілюструє рис. 12.56.
Мал. 12.56. Налаштування паттерна Команда
Досить часто перед тим, як зважитися на замовлення ПО, організація проводить бізнес-моделювання. Цілі бізнес-моделювання:
q відобразити структуру і процеси діяльності організації;
q чітко показати, комплексне і, головне, однакове розуміння потреб організації як співробітниками, так і майбутніми розробниками ПЗ;
q сформувати реальні вимоги до програмного забезпечення діяльності організації.
Для досягнення цих цілей розробляються дві моделі: Q бізнес-модель Use Case; а бізнес-об'єктна модель.
Бізнес-модель Use Case задає зовнішнє уявлення бізнес-процесів організації (з точки зору зовнішнього середовища - клієнтів і партнерів).
Як показано на рис. 12.57, бізнес-модель Use Case будується за допомогою бізнес-акторів і бізнес-елементів Use Case - простого розширення засобів, використовуваних в звичайних діаграмах Use Case.
Мал. 12.57. Фрагмент бізнес-моделі Use Case для аеропорту
Бізнес-актори визначають зовнішні сутності і людей, з якими взаємодіє бізнес. Бізнес-актор представляє собою людину, але інформаційна система, що взаємодіє з бізнесом, також може грати роль такого актора.
Бізнес-елементи Use Case зображують різні робочі потоки бізнесу. Послідовності дій в бізнес-елементах Use Case зазвичай описуються діаграмами діяльності.
Бізнес-об'єктна модель відображає внутрішнє представлення бізнес-процесів організації (з точки зору її співробітників).
Як показано на рис. 12.58, бізнес-об'єктна модель будується за допомогою бізнес-працівників і бізнес-сутностей - класів зі спеціальними стереотипами. Ці класи мають спеціальні графічні позначення.
Мал. 12.58. Фрагмент бізнес-об'єктної моделі аеропорту
Бізнес-працівник - абстракція людини, чинного в бізнесі. Бізнес-суті є «предметами», робочою або використовуваними бізнес-працівниками у міру виконання бізнес-елемента Use Case. Наприклад, бізнес-сутність являє собою документ або істотну частину продукту. Фактично бізнес-об'єктна модель відображається за допомогою діаграм класів.
1. Поясніть два підходи до моделювання поведінки системи. Поясніть переваги і недоліки кожного з цих підходів.
2. Охарактеризуйте вершини і дуги діаграми схем станів. В чому полягає призначення цієї діаграми?
3. Як відображаються дії в станах діаграми схем станів?
4. Як показуються умовні переходи між станами?
5. Як задаються вкладені стану в діаграмах схем станів?
6. Поясніть поняття історичного підстану.
7. Охарактеризуйте засоби і можливості діаграми діяльності.
8. Коли не слід застосовувати діаграму діяльності?
9. Які засоби діаграми діяльності дозволяють відобразити паралельні дії?
10. Навіщо в діаграму діяльності введені плавальні доріжки?
11. Як видається ім'я об'єкта в діаграмі співпраці?
12. Поясніть синтаксис уявлення властивості в діаграмі співпраці.
13. Які стереотипи видимості використовуються в діаграмі співпраці? Поясніть їх зміст.
14. У якій формі записуються повідомлення в мові UML? Поясніть зміст повідомлення.
15. У якому відношенні знаходяться повідомлення і дії? Перерахуйте різновиди дій.
16. Чим відрізняється процедурний потік від асинхронного потоку повідомлень?
17. Як вказується повторення повідомлень?
18. Як показати розгалуження повідомлень?
19. Що спільного в діаграмі послідовності і діаграмі співпраці? Чим вони відрізняються один від одного?
20. Як відображається порядок передачі повідомлень в діаграмі послідовності?
21. Коли зручніше застосовувати діаграми послідовності?
22. З яких елементів складається діаграма Use Case?
23. Які відносини дозволені між елементами діаграми Use Case?
24. Для чого застосовують діаграми Use Case?
25. Чим відрізняються один від одного відносини включення і розширення з точки зору управління?
26. Яке призначення специфікації елемента Use Case і як вона оформляється?
27. Що таке сценарій елемента Use Case?
28. Як документується відношення включення?
29. Як документується відношення розширення?
30. Який порядок побудови моделі вимог?
31. Яке призначення кооперації? Які складові її утворюють?
32. Чи можуть різні кооперації використовувати однакові класи? Обгрунтуйте відповідь.
33. Що таке патерн?
34. Чим патерн відрізняється від кооперації? Чим вони схожі?
35. Як описується патерн?
36. Що потрібно зробити для застосування патерну?
37. Які цілі бізнес-моделювання?
38. З яких частин складається бізнес-модель? На що схожі ці частини? У чому їх своєрідність?