6. Розробка і оцінка архітектури на основі сценаріїв
При проектуванні архітектури системи на основі вимог, зафіксованих у вигляді варіантів використання, перші можливі кроки полягають в наступному.
Виділення компонентів
Вибирається набір "основних" сценаріїв використання — найбільш істотних і виконуваних частіше за інших.
Виходячи з досвіду проектувальників, вибраного архітектурного стилю (див. наступну лекцію) і вимог до переносимості і зручності супроводу системи визначаються компоненти, що відповідають за певні дії в рамках цих сценаріїв, тобто за розв’язування певних підзадач.
Кожен сценарій використання системи представляється у вигляді послідовності обміну повідомленнями між отриманими компонентами.
При виникненні додаткових добре виділених підзадач додаються нові компоненти, і сценарії уточнюються.
Визначення інтерфейсів компонентів
Для кожного компоненту в результаті виділяється його інтерфейс — набір повідомлень, які він приймає від інших компонентів і посилає їм.
Розглядаються "неосновні" сценарії, які так само розбиваються на послідовності обміну повідомленнями з використанням, по можливості, вже визначених інтерфейсів.
Якщо інтерфейси недостатні, вони розширюються.
Якщо інтерфейс компоненту дуже великий, або компонент відповідає за багато функцій, він розбивається на дрібніші.
Уточнення набору компонентів
Там, де це необхідно через вимоги ефективності або зручності супроводу, декілька компонентів можуть бути об'єднані в один.
Там, де це необхідно для зручності супроводу або надійності, один компонент може бути роздільний на декілька.
Досягнення потрібних властивостей.
Все це робиться до тих пір, поки не виконаються наступні умови:
Всі сценарії використання реалізуються у вигляді послідовностей обміну повідомленнями між компонентами в рамках їх інтерфейсів.
Набір компонентів достатній для забезпечення всієї потрібної функціональності, зручний для супроводу або портування на інші платформи і не викликає помітних проблем продуктивності.
Кожен компонент має невеликий і чітко окреслений круг розв’язуваних задач і строго визначений, збалансований за розміром інтерфейс.
На основі можливих сценаріїв використання або модифікації системи можливий також аналіз характеристик архітектури і оцінка її придатності для поставлених завдань або порівняльний аналіз декількох архітектур. Це так званий метод аналізу архітектури ПЗ (Software Architecture Analysis Method, SAAM) [14]. Основні його кроки наступні.
Визначити набір сценаріїв дій користувачів або зовнішніх систем, що використовують деякі можливості, які можуть вже плануватися для реалізації в системі або бути новими. Сценарії повинні бути значущі для конкретних зацікавлених осіб, будь то користувач, розробник, відповідальний за супровід, представник контролюючої організації і ін. Чим повніше набір сценаріїв, тим вище буде якість аналізу. Можна також оцінити частоту появи і важливість сценаріїв, можливий збиток від неможливості їх виконати.
Визначити архітектуру (або декілька порівнюваних архітектур). Це повинно бути зроблено у формі, зрозумілій всім учасникам оцінки.
Класифікувати сценарії. Для кожного сценарію з набору повинно бути визначено, чи підтримується він вже даною архітектурою або для його підтримки потрібно вносити до неї зміни. Сценарій може підтримуватися, тобто його виконання не потребуватиме внесення змін ні до одного з компонентів, або ж не підтримуватися, якщо його виконання вимагає змін в описі поведінки одного або декількох компонентів або змін в їх інтерфейсах. Підтримка сценарію означає, що особа, зацікавлена в його виконанні, оцінює ступінь підтримки як достатню, а необхідні при цьому дії — як достатньо зручні.
Оцінити сценарії. Визначити, які з сценаріїв повністю підтримуються даною архітектурою. Для кожного непідтримуваного сценарію треба визначити необхідні зміни в архітектурі — внесення нових компонентів, зміни в тих, що існують, зміни зв'язків і способів взаємодії. Якщо є можливість, варто оцінити трудомісткість внесення таких змін.
Виявити взаємодію сценаріїв. Визначити які компоненти потрібно змінювати для непідтримуваних сценаріїв; якщо потрібно змінювати один компонент для підтримки декількох сценаріїв — такі сценарії називають взаємодіючими. Потрібно оцінити смислові зв'язки між взаємодіючими сценаріями.
Мала зв'язаність за змістом між взаємодіючими сценаріями означає, що компоненти, в яких вони взаємодіють, виконують слабо зв'язані між собою завдання і їх варто декомпозувати.
Компоненти, в яких взаємодіють багато (більше два) сценаріїв, також є можливими проблемними місцями.
Оцінити архітектуру в цілому (або порівняти декілька заданих архітектур). Для цього треба використовувати оцінки важливості сценаріїв і ступінь їх підтримки архітектурою.
Контрольні запитання
Яка мета аналізу області розв’язків?
Що розуміють під архітектурою ПЗ?
Що розуміють під проектуванням архітектури ПЗ?
Що називають компонентом ПЗ в широкому та вузькому розумінні?
Що розуміють під компонентною моделлю?
Перелічити різні погляди на архітектуру ПЗ. Які компоненти архітектури ПЗ розглядаються при цьому?
Вказати характеристики ПЗ, на які впливає архітектура.
Що потрібно для побудови «хорошої архітектури»?
Яку архітектуру слід застосовувати для підвищення ефективності ПЗ? Відповідь аргументувати.
Яку архітектуру слід застосовувати для підвищення зручності супроводу ПЗ? Відповідь аргументувати.
Яку архітектуру слід застосовувати для підвищення надійності ПЗ? Відповідь аргументувати.
В чому полягає особливість забезпечення характеристик зручності і надійності при розробці архітектури ПЗ?
Які основні завдання слід вирішити для розробки архітектури ПЗ?
Які ви знаєте основні класи архітектур програмних засобів?
Охарактеризувати архітектуру «цілісна програма».
Охарактеризувати архітектуру «Комплекс автономно виконуваних програм».
Охарактеризувати архітектуру «Шарова програмна система».
Охарактеризувати архітектуру «Колектив паралельно виконуваних програм».
Поняття про конвеєр, його характеристики.
Поняття порту повідомлень.
Охарактеризувати систему з портами повідомлень.
Охарактеризувати види програмних систем з портами повідомлень.
Поняття про архітектурні функції ПЗ.
Які існують види контролю архітектури ПЗ?
Охарактеризувати суміжний контроль архітектури ПЗ.
Охарактеризувати контроль шляхом ручної імітації архітектури ПЗ.
Охарактеризувати кроки проектування архітектури системи на основі вимог.
Охарактеризувати кроки проектування архітектури системи методом аналізу архітектури ПЗ.