Завдання

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

2. На основі завдань вашого проекту визначити обсяг необхідного аналізу архітектури.

3. Визначити типи необхідного архітектурного аналізу та методики, які найбільш підходять для вашого проекту, обґрунтувати вибір.

4. Виконати архітектурний аналіз вашого проекту, занести результати аналізу до звіту.

5. Дослідити методи архітектурного аналізу більш детально, ніж було розглянуто у лекціях, і визначити як вони могли б бути використані у вашому проекті.

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

• Опис завдань та обсягу проведення архітектурного аналізу.

• Обґрунтування вибору типів та методик архітектурного аналізу.

• Результати проведеного архітектурного аналізу.

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

1. Що таке архітектурний аналіз?

2. Які основні цілі архітектурного аналізу?

3. Які архітектурні аспекти аналізують?

4. Які категорії методик архітектурного аналізу вам відомі?

5. У чому суть АТАМ методу?

6. У чому суть методів аналізу архітектури на основі моделей?

7. Що таке інструмент XTEAM, для чого він може бути застосований?

МОДУЛЬ №2

Дослідження та реалізація архітектури програмного забезпечення

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

Створення та дослідження архітектурного прототипу програмного забезпечення

Мета:отримати практичні навички створення прототипів ПЗ, використання архітектурних каркасів та проміжного ПЗ.

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

Розробка ПЗ на основі спланованої архітектури є значною мірою проблемою відображення Підтримка відображення означає, що нам слід запевнитися, в тому, що всі архітектурні задуми були втілені у готовій системі. Розглянемо реалізацію відображення для декількох видів проектних рішень. Проектні рішення щодо компонентів і з’єднувачів поділяють функціональність застосування на елементи обчислень і елементи комунікації. В цілому, мови програмування та середовища розробки забезпечують механізмами, такими як пакети, бібліотеки, класи, тощо. Завдання полягає в тому, щоб підтримувати відповідність між поняттями, визначеними на рівні архітектури і поняттями на рівні технології реалізації. Інтерфейси на архітектурному рівні можна відображати по різному. Якщо інтерфейси на рівні архітектури – прості виклики процедур, то і відобразити їх буде не складно. Найскладніше відобразити стани кінцевого автомату, чи протоколи.

Після введення системи в дію, архітектура неминуче змінюється: для здійснення обслуговування, через плин часу, завдяки новим даним. Реалізація системи може бути джерелом нових даних про систему, так, як ми дізнаємося більше про проект у цілому. У такій ситуації доволі важко синхронізувати архітектуру та реалізовану систему. Односторонні відображення завжди легші: потрібно лише зрозуміти вплив на реалізацію системи зміни архітектурних проектних рішень. Двосторонні відображення складніші: потрібно зрозуміти, як зміни при реалізації, що впливають на архітектурні проектні рішення, повинні бути репрезентовані на архітектурному рівні.

Під час розробки системи ідеальним підходом буде спочатку визначитися з архітектурою, а вже потім обрати технології, що найбільш підходять для реалізації системи. Це досить важко. Непоганою стратегією є подолання бар’єру між архітектурними концептами і системною реалізацією за допомогою каркасів реалізації архітектури. Каркас реалізації архітектури – це частина програмного комплексу, що виконує роль мосту між певним архітектурним стилем та набором технологій реалізації [2]. Він забезпечує наявність основних елементів архітектурного стилю у коді застосування, таким чином допомагаючи розробникам створювати систему, що буде строго відповідати накладеним обмеженням і вимогам архітектурного стилю. Канонічним прикладом слугує бібліотека I/O (stdio), під ЮНІКС та іншими операційними системами, що підтримує архітектурний стиль «Канали та фільтри». Каркаси розроблені для того, щоб допомагати розробникам дотримуватися архітектурного стилю, але не забороняють розробникам порушувати його, якщо вони дуже цього забажають. Каркаси звичайно розглядаються, як базова інфраструктура, або підструктура з архітектурної точки зору.

На ринку доступна велика кількість технологій для реалізації ПЗ, CORBA, COM/DCOM, JavaBeans, .NET, Java Message Service (JMS), та ін. Вони всі досить схожі, наприклад усі вони надають розробникам сервіси, що не доступні на рівні самої операційної системи / мови програмування. Дійсно, каркаси реалізації архітектури є у деякій мірі проміжним ПЗ (middleware). Існує достатньо тонка різниця у тому, як вони виникають і розвиваються. Проміжне ПЗ, як правило, ґрунтується на наборі сервісів, які потрібні розробникам, наприклад CORBA забезпечує неоднорідність мови, прозорість мережі, мобільність. Каркаси ж ґрунтуються на певному архітектурному стилі, який розробник планує використовувати. Зосереджуючи свою увагу на сервісах проміжного ПЗ, розробники часто обирають рішення, які мають істотний вплив на архітектуру. Насправді, проміжне ПЗ може нав’язувати архітектурний стиль. Так CORBA передбачає застосування стилю «Розподілені об’єкти», JMS використовує стиль «розподілених неявних викликів». Якщо це розуміти, то можна уникнути проблем, на кшталт тих, коли хвіст виляє собакою, а не навпаки!