Архітектура програмного забезпечення: види, опис, розробка

Зараз мало знайдеться людей, які будуть сперечатися з твердженням, що наш світ все більше залежить від програмного забезпечення (ПО). І це не дивно. Адже використовується в стільникових телефонах, комплексних системах управління повітряним рухом, на персональних комп'ютерах, електроніці автомобілів і багато де ще. Безліч нововведень, які нами сприймаються як даність, а також велику кількість різних організацій на кшталт "Яндекс", Amazon чи Google просто неможливі без програмного забезпечення. Та навіть у традиційних торговому, громадському та фінансовому секторах обійтися без ПО дуже складно.

Загальна інформація

Варто тільки торкнутися поняття архітектури, так відразу стає зрозуміло одне – відсутність у визначеннях не існує. Тому, щоб не збивати читачів з пантелику, у статті будуть використані стандарти IEEE 1471 і IEEE Std 1472000 як зразки для розгляду. А зараз давайте розберемо, що ж собою являє архітектура. Під цим терміном розуміється організація системи, що втілюється в її компонентах, взаємовідносинах між ними і оточенням, а також принципи, що визначають її проектування і розвиток. Однак спочатку давайте згадаємо про тих, хто вніс чималий внесок у розробку теорії та концепції програмного забезпечення.


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

Трохи термінології

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

Вплив архітектури на структуру

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

Вплив архітектури на поведінку

Його просто неможливо недооцінити. Проектування архітектури програмного забезпечення надає великий вплив на її реалізацію і подальшу працездатність. Поведінка, можливі зависання, проблеми тощо дуже сильно залежать від того, як все розвивалося з самого початку. Архітектура впливає на взаємодію між структурними елементами, повинна забезпечувати передачу даних саме туди, куди необхідно, щоб в кінцевому підсумку отримати бажаний результат. Як це відбувається з нашими стандартами? Можна побачити невелику схему діяльності. Припустимо, у нас є підприємство. Необхідно зробити, щоб службовець брав замовлення з допомогою екземпляра класу «Бланк». В нього заносяться всі необхідні відомості про клієнта. Якщо замовлення оформляється вперше, то відомості заносяться в «Бланк» з допомогою системи управління. Потім використовується екземпляр класу «Початок обробки замовлення», який запускає всі потрібні процеси на підприємстві. Всього використовується п'ять елементів. При цьому спостерігається певна залежність. Наприклад, оформлення замовлення неможливо без службовця. А якщо не буде заповнений «Бланк», то він не буде прийнятий до виконання.

Концентрація архітектури на суттєвих елементах

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

Урівноваження потреб зацікавлених осіб

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

Архітектура базується на логічному обґрунтуванні

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

Про архітектурному стилі

Що і як у даному випадку? Якщо подивитися опис архітектури програмного забезпечення для багатьох продуктів, то можна помітити, що вони будуються на основі систем, які використовують подібні набори інтересів. Ряд подібностей може бути оформлений у певний стиль. Він, у свою чергу, може розглядати як особливий вид шаблону, дуже складний і складовою. Це – кодифікатор досвіду, і для розробників досить непогано використовувати його повторно. Адже це дозволить зробити подібну роботу швидко і оперативно. Які основні архітектури програмного забезпечення за стилем виділяють? В якості прикладів можна навести: Розподілений. Канали і фільтри. З централізованою обробкою даних. Побудований на правилах. Слід зазначити, що окремі системи можуть демонструвати наявність більше одного стилю. Що є підтвердженням цих слів? В першу чергу можна згадати про архітектурний стиль Шоу і Гарлана. Як він проявляється? Архітектурний стиль – це, по суті, номенклатура компонентів, а також типів сполучних ланок і наборів умов, за якими вони можуть бути поєднані. Повторне використання досвіду у вигляді застосування архітектурного стилю дозволяє полегшити життя завдяки тому, що він вже непогано документований і обґрунтоване раціональне зерно використання чогось.

Про вплив оточення. І навпаки

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

Про видовому розмаїтті

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