Архітектура програми - особливості, опис і вимоги

Архітектура програми - особливості, опис і вимоги

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

Ввідна інформація

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


Про критерії

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

На що робити ставку?

Працюючи з архітектурою, увагу слід приділити:

  1. Ефективності системи. Тобто проектування архітектури додатка має створювати таке програмне забезпечення, яке зможе вирішувати поставлені завдання і добре виконувати покладені на нього функції в різних умовах. Насамперед тут слід згадати надійність, продуктивність, безпеку, масштабованість (здатність справлятися зі збільшенням навантаження).
  2. Гнучкості системи. Будь-який, навіть найдосконаліший додаток доводиться з часом змінювати. Адже можуть змінитися існуючі вимоги або додатися нові. Чим зручніше і швидше цей процес можна завершити з меншою кількістю помилок і проблем, тим конкурентоспроможніша і гнучкіша система. Тому необхідно стежити за тим, щоб прийнятий підхід не "вирубував в камені" всі дії.
  3. Розширюваності системи. Можливість додати нові функції і сутності, не порушуючи основну структуру, говорить про продуманість програми. На початковому етапі має сенс закладати виключно основний і необхідний функціонал. Але при цьому повинна бути передбачена можливість нарощування наданих можливостей у міру виникнення необхідності. Причому таким чином, щоб на це витрачалася мінімальна кількість сил. Це настільки важливо, що навіть сформульовано у вигляді другого принципу SOLID: програмні сутності відкриті для розширення, закриті для модифікації. Тобто архітектура повинна бути такою, щоб можна було написати новий код, але не довелося змінювати вже існуючий.

А що ще?

Цими трьома критеріями архітектура програмного додатку не обмежена:

  1. Масштабованість розробки. Архітектура повинна передбачати можливість забезпечити паралельність процесу розробки, щоб збільшити кількість людей, які працюють над проектом.
  2. Тестованість програми. Код, який легко перевіряти, містить в собі меншу кількість помилок і надійніше працює. До того ж це ще й підштовхує до формування хорошого дизайну коду, що також полегшує подальшу роботу з ним.
  3. Можливість повторного використання. Систему слід проектувати таким чином, щоб її окремі фрагменти можна було застосовувати в інших проектах.
  4. Хороша структурованість, читаність і зрозумілість коду. Над програмами, як правило, працює велика кількість людей. Часто зустрічається ситуація, коли приходять нові або йдуть старожили. Архітектура програми повинна враховувати це. І всі напрацювання повинні давати можливість відносно швидко і легко розібратися в створюваній системі новим людям. У цьому допомагає хороша структурованість проекту, відсутність дублювання, адекватне оформлення та документація супроводу (необов 'язково, але бажано).

І що ж з цього випливає?

Незважаючи на наявність великої кількості критеріїв, як правило, пріоритетним вважається завдання зниження складності. А для цього нічого, крім як ділити на частини, не придумали. Більшості людей це відомо як принцип "розділяй і володарюй". Але якщо говорити професійною мовою, то це звичайна ієрархічна декомпозиція. Що це означає на практиці? Є одна велика цільова система. Наприклад: архітектура корпоративних програмних додатків. Вона складається з безлічі простих підсистем. Кожна з них має свої елементи. І так до тих пір, поки не будуть виділені невеликі частини, зрозумілі і легкі в роботі. Що добре, так це те, що таке рішення є не тільки єдиним відомим, але ще й універсальним. Крім зниження складності воно дозволяє ще забезпечити гнучкість системи, надає можливості для масштабування і підвищує стійкість кінцевого продукту.

Розгляд прикладу

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

Перетворення спагетті-коду на конструктор

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


1. Масштабованість - дозволяє розширювати систему і покращувати її продуктивність завдяки додаванню нових модулів.

2. Ремонтопридатність - зміна однієї частини програми не потребує втручання в інші.

3. Замінюваність - декілька додатків легко можуть виконувати потрібні функції.

4. Тестованість - часто програми можна відокремити і окремо перевірити (полагодити).

5. Перекористування - окремий додаток можна використовувати в інших програмах і оточеннях.

6. Супроводжуваність - програма легко розбивається на складові частини, які нескладно зрозуміти.

Як виглядає сам процес?

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


Ієрархічна декомпозиція

Багато хто допускає тут помилку, рубаючи додаток відразу на сотні класів. Правильніший підхід - розбити систему на великі модулі (пакети), що описують її роботу в загальному вигляді. Потім вони аналізуються і при необхідності поділяються на більш дрібні об 'єкти. Перед початком роботи бажано розділити всю систему на окремі смислові блоки хоча б подумки. Часто вистачає виділення всього двох рівнів (пакети і класи). Незважаючи на свою очевидність, дана думка не є такою банальною, як здається на перший погляд. Як приклад можна навести такий поширений архітектурний шаблон, як "Модель-Вид-Контролер" ", також відомий як MVC. На першому рівні можна розмістити найбільші складові частини. Як приклад можна навести наступне: користувацький інтерфейс, робота з базою даних, встановлення лінії зв 'язку з певним об' єктом. А вже далі створювати класи за потребою. Але не потрібно занадто старанно.

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

Функціональна декомпозиція

Поділ на модулі проводиться, ґрунтуючись на завданнях, які переслідуються системою. При цьому основну можна, як правило, розбити на кілька менших за розміром. У цьому випадку необхідно стежити, щоб вони могли виконуватися/вирішуватися незалежно один від одного. Виходячи з цього, бажано, щоб додаток відповідав за вирішення певної частини завдання і виконував необхідну для цього функцію. Крім того, слід перейматися вступом усіх необхідних для успішного функціонування даних. Бажано домагатися наявності результату в умовах відсутності допомоги інших модулів, тільки використовуючи свої вхідні дані. Що з цього випливає? Під модулем розуміється не якийсь довільний шматок коду, а повноцінна програмна одиниця, що є функціонально осмисленою і закінченою.

Комбінована декомпозиція

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

  1. Висока сполученість. Цей параметр показує, що модуль сфокусований на одній вузькій проблемі. Пов 'язаність досягається тільки в цьому випадку. Якщо ж він виконує різнорідні функції і не пов 'язані між собою обов' язки, то це говорить про наявність істотних проблем.
  2. Слабка зв 'язаність. Цей параметр показує, що окремі модулі, з яких будується система, незалежні. Як допустима, але малоприємна альтернатива - слабо пов 'язані між собою. Але при цьому вони повинні мати можливості для взаємодії.

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


Насамкінець

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