РОЗДІЛ. 6. СТРУКТУРА ТА АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ 2

6.1 Поняття архітектури програмного забезпечення 2

6.1.1 Якість архітектури. Ознаки загниваючого проекту 3

6.1.2 Як зробити кращу архітектуру 4

6.1.3 Принципи гарної архітектури 5

6.1.4 Повторне використання коду 10

6.1.5 Framework-системи 11

6.1.6 Архітектура CMF-системи 14

6.1.7 Маленькі бібліотеки 17

6.1.8 Використання функцій 19

6.1.8 Патерни проектування 21

6.1.9 Модель-подання-контролера (Model View Controller) 27

Розділ. 6. Структура та архітектура програмного забезпечення

6.1 Поняття архітектури програмного забезпечення

Архітектура програмного забезпечення ( англ. software architecture ) - це структура програми або обчислювальної системи, яка включає програмні компоненти, видимі зовні властивості цих компонентів, а також відносини між ними. Цей термін стосується також документування архітектури програмного забезпечення. Документування архітектури ПЗ спрощує процес комунікації між зацікавленими особами ( англ. stakeholders ), дозволяє зафіксувати прийняті на ранніх етапах проектування рішення про високорівневі дизайні системи і дозволяє використовувати компоненти цього дизайну і шаблони повторно в інших проектах.

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

Архітектура ПЗ, яку також можна уявити собі у вигляді розробки стратегії - це діяльність, пов'язана з визначенням глобальних обмежень, що накладаються на проектування системи, такі як вибір парадигми програмування, архітектурних стилів, стандарти розробки ПЗ, засновані на використанні компонентів, принципи проектування та обмеження, накладаються державним законодавством. Детальне проектування, тобто розробка тактики - це діяльність, пов'язана з визначенням локальних обмежень проекту, такі як шаблони проектування, архітектурні моделі, ідіоми програмування і рефакторинга. Згідно "гіпотезі напруги / околиці" (Intension / Locality Hyphotysis), відмінність між архітектурним і детальним проектуванням визначається критерієм околиці (Locality Criteria), згідно з яким твердження, що дизайн ПО не є локальним (а є архітектурним) істинно тоді і тільки тоді, коли програма, яка відповідає цьому критерію може бути розширена в програму, яка не задовольняє йому. Наприклад, стиль програми, клієнт-сервер є архітектурним стилем (стратегічним дизайном), тому що програма, яка побудована на цьому принципі, може бути розширена в програму, яка не є клієнт-сервером, наприклад, шляхом додавання peer-to-peer вузлів.

Архітектура є проектуванням (дизайном), але не всякий дизайн є архітектурним дизайном. На практиці, архітектор визначає межу між архітектурою програмного забезпечення (архітектурним дизайном) і детальним дизайном (неархітектурним проектуванням). Не існує правил чи інструкцій, як зробити це, які підходять для будь-якого випадку.

6.1.1 Якість архітектури. Ознаки загниваючого проекту

Отже, будь-який програмний код має взаємозалежності одних частин від інших. Класи вимагають наявності інших класів, одні функції викликають інші і т.д. У міру зростання будь-якого проекту взаємозалежностей стає все більше і більше. Вимоги до проекту змінюються, розробники іноді вносять швидкі й не завжди вдалі рішення. Якщо залежностями грамотно не управляти, то проект неминуче почне загнивати. Код стає складніше розуміти, він частіше ламається, стає менш гнучким і важким для повторного використання. У результаті швидкість розробки падає, проект чинить опір змінам, і ось вже серед розробників звучать заклики «Давайте все переробимо! Наступного разу ми зробимо супер-архітектуру ». Ось найбільш поширені ознаки поганого або загниваючого в плані коду проекту:

- Закритість (rigid) - система відчайдушно чинить опір змінам, неможливо сказати, скільки займе реалізація тієї або іншої функціональності, тому що зміни, швидше за все, торкнуться багатьох компонентів системи. Через це вносити зміни стає занадто дорого, тому що вони вимагають багато часу.

- Нестійкість, крихкість (fragile) - система ламається в непередбачених місцях, хоча зміни, були проведені до цього, зламані компоненти явно не зачіпали.

- Нерухомість або монолітність (not reusable) - система побудована таким чином і характер залежностей такий, що використовувати будь-які компоненти окремо від інших не представляється можливим.

- В'язкість (high viscosity) - код проекту такий, що зробити що-небудь неправильно набагато простіше, ніж зробити щось правильно.

- Невиправдані повторення (high code duplication) - розмір проекту набагато більший, ніж він міг би бути, якби абстракції застосовувалися частіше.

- Надмірна складність (overcomplicated design) - проект містить рішення, користь від яких неочевидна, вони приховують реальну суть системи, ускладнюючи її розуміння і розвиток.

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