Модульна архітектура ПЗ

1. Декомпозиція

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

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

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

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

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

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

2. Переваги модульної архітектури

Використання принципу ієрархічної декомпозиції дозволяє позбавитися хаосу в тисячах класів твого коду. Пам'ятаєш, що твій код розбивається за пакетами (package) та підпакетами? Це і є один із проявів ієрархічної декомпозиції.

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

Ось основні з них:

• Масштабованість (Scalability) – можливість розширювати систему та збільшувати її продуктивність за рахунок додавання нових модулів.
• Ремонтопридатність (Maintainability) – зміна одного модуля не потребує зміни інших модулів.
• Замінність модулів (Swappability) – модуль легко замінити іншим.
• Можливість тестування (Unit Testing) – модуль можна від'єднати від решти і протестувати/полагодити.
• Перевикористання (Reusability) – модуль може бути перевикористаний в інших програмах та іншому оточенні.
• Супроводжуваність (Maintenance) – розбиту на модулі програму легко розуміти і супроводжувати.

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

Тому більшість визначень у тій чи іншій формі зводяться до наступного:

"Архітектура ідентифікує головні компоненти системи та способи їх взаємодії. Також це вибір таких рішень, які інтерпретуються як основоположні та не підлягають зміні в майбутньому".

"Архітектура – це організація системи, втілена в її компонентах, їх відносинах між собою і з оточенням. Система - це набір компонентів, об'єднаних для виконання певної функції."

Таким чином, хороша архітектура – це, перш за все, модульна/блочна архітектура. Щоб отримати хорошу архітектуру, треба знати, як правильно робити декомпозицію системи. Отже, необхідно розуміти, яка декомпозиція вважається “правильною” і як її краще проводити.