Завдання

1. Визначити основні архітектурні проблеми, що мають стосунок до вашого проекту (принаймні три). Чому ці проблеми мають значення у вашому проекті?

2. Визначити набір точок зору на архітектуру системи, керуючись проблемами, що визначені у попередньому завданні (як мінімум одна точка зору на одну проблему).

3. Обрати нотацію моделювання та візуалізацію для кожної точки зору.

4. Змоделювати архітектуру вашої системи, фіксуючи у моделі рішення, пов’язані з визначеним набором точок зору. Переконатися, що усі основні компоненти та з’єднувачі репрезентовані у ваших моделях.

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

• Перелік архітектурно важливих проблеми для вашої системи з обґрунтуванням їх важливості.

• Обґрунтування вибору точок зору, нотацій моделювання, та візуалізацій. Переконатися в тому, що у звіт включено будь-які важливі обмеження (такі як стиль або обмеження в реалізації) яким повинна відповідати архітектура вашої системи.

• Опис типів з’єднувачів та їх застосованих аспектів.

• Усі побудовані візуалізації архітектурної моделі та обґрунтування ваших архітектурних рішень (це повинно бути основним розділом вашого звіту).

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

• Будь-які додаткові доречні спостереження та цікаві відкриття.

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

1. Що таке архітектурна модель?

2. Що таке архітектурна нотація?

3. Які основні характеристики архітектурних моделей?

4. Що означає неоднозначність, точність та адекватність моделі?

5. Що таке точка зору та подання архітектури?

6. Які основні широко використовувані точки зору на архітектуру вам відомі?

7. Що таке несумісність подань і як їй запобігти?

8. Які архітектурні нотації вам відомі? У чому їх особливість?

9. Що таке архітектурна візуалізація?

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

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

12. Які переваги графічної візуалізації вам відомі?

13. Які переваги гібридної візуалізації вам відомі?

Лабораторна робота №1.4 Аналіз архітектури програмного забезпечення

Мета:отримати практичні навички підготовки та проведення архітектурного аналізу.

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

Архітектурний аналіз, це діяльність під час якої визначають важливі системні властивості, використовуючи системні архітектурні моделі [2]. Аналіз неформальних архітектурних моделей допомагає архітекторам отримати уточнення від можливих покупців системи, допомагає менеджерам окреслити рамки проекту, але не так корисний для розробників. Аналіз формальних архітектурних моделей допомагає архітекторам визначитися з правильною «компоновкою компонентів», дозволяє визначити правильні комерційні компоненти, надає змогу автоматичної генерації коду, але з цього не має користі при обговоренням певних аспектів з зацікавленими особами, що не мають технічних навичок.

Основні цілі архітектурного аналізу – це: повнота, узгодженість, сумісність, правильність кінцевого продукту. Повнота являється як зовнішньою так і внутрішньою ціллю. Вона є зовнішньою по відношенню до системних вимог, у порівнянні з складністю великих систем. По відношенню до архітектурних «намірів», та нотацій моделювання вона є внутрішньою: чи всі елементи були змодельовані в нотації? Чи всі проектні рішення були охоплені? Узгодженість є внутрішньою властивістю архітектурної моделі, яка гарантує, що різні елементи моделі не суперечать один одному. Параметри перевірки архітектурної цілісності наступні: ім’я, інтерфейс, поведінка, взаємодія, уточнення. Сумісність це зовнішня властивість архітектурної моделі, яка гарантує, що архітектурна модель дотримується принципів та обмежень архітектурного стилю та архітектурного стандарту. Правильність це зовнішня властивість архітектурної моделі, яка забезпечує відповідність архітектури системній специфікації та системній реалізації.

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

Існують такі архітектурні питання: структурні характеристики, поведінкові характеристики, характеристики взаємодії, нефункціональні характеристики. Основні види аналізу: статичний аналіз – означає перевірку властивості однієї або кількох моделей програмного продукту, без виконання (запуску, прогону) цієї моделі; динамічний аналіз – передбачає фактичне виконання, або імітації роботи системи; на основі сценаріїв – передбачає перегляд найбільш ймовірних сценаріїв використання системи. Аналіз може бути проведеним за участю людини, або ж частково чи повністю автоматизовано.

Усі техніки аналізу архітектури ПЗ можна поділити на наступні категорії: на основі інспекцій та переглядів, на основі моделей, і на основі імітації. Під час інспекцій та перевірок, архітектурні моделі вивчають люди на відповідність тим, чи іншим властивостям. Хоча ручні методи перевірки можуть бути достатньо дорогими, проте вони корисні у разі, якщо опис архітектури проводився неформально, а також вони визначають «м’які» системні властивості, такі як масштабованість та адаптованість. Прикладом може слугувати ATAM (architectural trade-off analysis method) [3].

Аналіз архітектури, на основі моделі передбачає техніки аналізу, які керуються описом архітектури для виявлення її властивостей. Ці методи є інструментальними, потенційно дешевими, зазвичай їх використовують для виявлення «жорстких» архітектурних властивостей тому, що вони фокусуються на єдиному архітектурному аспекті. Модельно-орієнтований та інспекційно-орієнтований аналізи зазвичай використовуються разом.

Аналіз на основі імітації потребує використання виконуваної системної моделі. Під час імітації не обов’язково вимагати поведінки системи, ідентичної до поведінки готової системи, через те, що багато низькорівневих системних параметрів можуть бути недоступні. Деякі архітектурні моделі можуть бути недоступні для імітації і потребують трансляції на мову імітування. Прикладом такого методу є XTEAM.