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

Опубликованно 11.08.2018 00:27

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Категория: Техника