Завдання

1. Завершити реалізацію застосування шляхом реалізації компонентів та проблемно-орієнтованих компонентів.

2. Побудувати архітектурну модель розгортання ПЗ, яка б підтримувала реалізацію необхідної для вашого проекту якості сервісу, виконати аналіз моделі.

3. Реалізувати розгортання розробленого застосування, підготувати його до демонстрації.

4. У ході роботи, обов’язково документувати будь-які зміни архітектури застосування (набору основних проектних рішень про систему).

5. До звіту необхідно включити таке:

• Один або два шматки коду (максимум 3–4 аркуші), показуючи як основні проблемно-орієнтовані компоненти реалізовані у застосуванні. Для кожного шматка вказати, який компонент показано, та забезпечте код коментарями, або поясненнями на один невеликий абзац.

• Опис того, якими були основні архітектурні рішення у застосуванні. Для кожного рішення вказати: а) саме рішення; б) атрибути якості, підтримувані таким рішенням; в) методики, техніки, шаблони, або ресурси третіх сторін, які використано г) як рішення відображені на загальну архітектуру. Розглянути хоча б три такі рішення. Можна також розглянути менш детально більше ніж три рішення, або ж лише три рішення, але детально, як слід.

• Візуалізацію архітектурної моделі розгортання, та результати її аналізу.

• Опис того, як архітектура застосування розвивалася протягом лабораторного проекту. На приклад, які рішення довелося переглянути, коли ви дізналися більше і почали краще розуміти систему та сторонні компоненти, що були обрані? Обов’язково пов’язати міркування з елементами архітектурної моделі та проектними рішеннями.

Контрольні запитання

1. Які основні підходи до реалізації архітектури вам відомі?

2. Що таке розгортання ПЗ?

3. Які є основні виклики розгортання та мобільності ПЗ?

4. Яку діяльність включає в себе розгортання ПЗ?

5. Які елементи обов’язково вимагає моделювання розгортання ПЗ?

6. Які парадигми мобільності ПЗ вам відомі? Які з цих парадигм були застосовані у вашому проекті? Чому?

Лабораторна робота №2.3

Дослідження шаблонів проектування

Мета: отримати практичні навички застосування шаблонів проектування для підвищення внутрішньої якості ПЗ.

Теоретичні відомості

Шаблон проектування це загальне повторно використовуване рішення проектних проблем, які часто зустрічаються [5]. Шаблон не є закінченим зразком, який можна безпосередньо транслювати в програмний код. Об'єктно-орієнтований шаблон найчастіше є зразком вирішення проблеми і відображає відношення між класами та об'єктами, без вказівки на те, як буде зрештою реалізоване це відношення. Розрізняють такі типи шаблонів: твірні шаблони, структурні шаблони, шаблони поведінки.

Твірні шаблони це шаблони проектування, що абстрагують процес інстанціювання. Вони допоможуть зробити систему незалежною від способу створення, композиції та представлення її об'єктів. Шаблон, що створює об'єкти, делегує інстанціювання іншому об'єктові. Ці шаблони важливі, коли система більше залежить від композиції об'єктів, ніж від спадкування класів. Таким чином, замість прямого кодування фіксованого набору поведінок, визначається невеликий набір фундаментальних поведінок, за допомогою композиції яких можна отримувати складніші. Шаблони, що породжують, інкапсулюють знання про конкретні класи, які застосовуються у системі та приховують деталі того, як ці класи створюються і стикуються між собою. Єдина інформація про об'єкти, що відома системі— їхні інтерфейси.

Структурні шаблони — шаблони проектування, у яких розглядається питання про те, як із класів та об'єктів утворюються більші за розмірами структури. Структурні шаблони рівня класу використовують спадковість для утворення композицій із інтерфейсів та реалізацій. Структурні шаблони рівня об'єкта компонують об'єкти для отримання нової функціональності. Додаткова гнучкість у цьому разі пов'язана з можливістю змінювати композицію об'єктів під час виконання, що є неприпустимим для статичної композиції класів.

Шаблони поведінки — шаблони проектування, що пов'язані з алгоритмами та розподілом обов'язків поміж об'єктів. Мова в них йде не тільки про самі об'єкти та класи, але й про типові способи їхньої взаємодії. Шаблони поведінки характеризують складний потік керування, котрий досить важко прослідкувати під час виконання програми. Увага акцентована не на потоці керування, а на зв'язках між об'єктами. У шаблонах поведінки рівня класу використовується спадкування — щоб розподілити поведінку поміж різних класів. У шаблонах поведінки рівня об'єкта використовується композиція. Деякі з них описують, як за допомогою кооперації багато рівноправних об'єктів пораються із завданням, котре жодному з них не під силу. Тут є важливим те, як об'єкти отримують інформацію про існування один одного. Об'єкти-колеги можуть зберігати посилання один на одного, але це посилює ступінь зв'язаності системи. За максимального рівня зв'язаності кожному об'єкту довелось би мати інформацію про всі інші. Деякі з наведених шаблонів вирішують цю проблему.