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

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

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

Огляд

Область комп'ютерних наук з моменту свого утворення зіткнулася з проблемами, пов'язаними зі складністю програмних систем. Раніше проблеми складності вирішувалися розробниками шляхом правильного вибору структур даних, розробки алгоритмів та застосування концепції розмежування повноважень. Хоча термін "архітектура програмного забезпечення" є відносно новим для індустрії розробки ПЗ, фундаментальні принципи цієї області невпорядковано застосовувалися піонерами розробки ПЗ починаючи з середини 1980-х. Перші спроби усвідомити і пояснити програмну архітектуру системи були повні неточностей і страждали від нестачі організованості, часто це була просто діаграма з блоків, сполучених лініями. У 1990-ті роки спостерігається спроба визначити і систематизувати основні аспекти даної дисципліни. Початковий набір шаблонів проектування, стилів дизайну, передового досвіду (best-practices), мов опису та формальна логіка були розроблені протягом цього часу.

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

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

Підсумок

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

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

Добре, ми з'ясували що архітектура це дуже важливий аспект розробки. Але що ж це таке? У контексті PHP5 додатки з упором в парадигму - це ієрархія класів, інтерфейси та схеми їх взаємодії.

Вибір або створення архітектури залежить від конкретних завдань. Наприклад, наскільки універсальним планується додаток, які модулі повинні бути присутніми, яка запланована навантаження на ресурс.

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

Якість архітектури

Ознаки загниваючого проекту

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

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

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

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

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

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

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

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

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

Принцип відкриття-закриття (Open Close Principle або OCP)

Програмні суті такі як класи, модулі та функції повинні бути відкриті для розширення, але закриті для змін.

Ви можете обговорювати його, коли пишете ваші класи, щоб бути впевненими в тому, що коли вам буде потрібно розширити поведінку, ви не повинні будете змінювати клас, але можете розширювати його. Подібний же принцип застосуємо для модулів, пакетів і бібліотек. Якщо у вас є бібліотека, що складається з множини класів, то є багато причин для того, щоб ви вважали за краще розширення замість зміни коду, який вже написаний (заради зворотної сумісності, повернення до попереднього тестування і т.д.). Це причина, по якій ми повинні бути впевнені, що наші модулі слідують Принципу відкриття-закриття. По відношенню до класів Принцип відкриття-закриття може бути гарантовано корисний за рахунок використання Абстрактних Класів і конкретних класів для реалізації їх поведінки. Це буде змушувати мати Конкретні Класи, що розширюють Абстрактні Класи замість їх зміни. Деякі приватні випадки цього принципу є Шаблонний Патерн і Стратег ічний Патерн (Template Pattern and Strategy Pattern).

Принцип інверсії залежностей

(Dependency Inversion Principle) - залежності всередині системи будуються на основі абстракцій. Модулі верхнього рівня не залежать від модулів нижнього рівня. Абстракції не залежать від подробиць.

Даний принцип дуже важливий і гідний докладного розгляду.

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

Повторне використання коду (англ. code reuse) - методологія проектування комп'ютерних та інших систем, що полягає в тому, що система (комп'ютерна програма, програмний модуль) частково або повністю повинна складатися з частин, написаних раніше компонентів і / або частин іншої системи. Повторне використання - основна методологія, яка застосовується для скорочення трудовитрат при розробці складних систем.

Найпоширеніший випадок повторного використання коду - бібліотеки програм. Бібліотеки надають загальну досить універсальну функціональність, яка покриває обрану предметну область. Приклади: Бібліотека функцій для роботи з комплексними числами, бібліотека функцій для роботи з 3D-графікою, бібліотека для використання протоколу TCP / IP, бібліотека для роботи з базами даних. Розробники нової програми можуть використовувати існуючі бібліотеки для вирішення своїх завдань.

Повторне використання коду за межами одного проекту практично неможливо, якщо у вас немає розробленого проектного каркаса [framework]. У різних проектах різні набори сервісів, що і ускладнює повторне використання об'єкта.

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

Framework-системи

Вступ

Що таке framework-система? Навіщо вона Вам потрібна? У чому вона Вам може допомогти? А в чому ні? У цьому документі я спробую дати відповіді на ці питання.

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

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

Отже, що таке framework?

Коли людина вирішує якесь завдання багато разів поспіль, він вчиться вирішувати її швидко і ефективно! З точки зору web-програмування, framework-система (CMF-система) це платформа, що дозволяє вирішувати завдання, які постійно виникають при створенні інтернет-додатків. Не варто думати, що CMF-система - це просто набір модулів для вирішення різнотипних завдань, яких в Інтернеті безліч. Framework-система це щось більше. Це:
• Термінологія, яка дозволяє розробникам говорити лаконічно про дуже складні речі;
• Набір архітектурних стандартів, які система накладає на інтернет-додатки. Це знімає з розробників необхідність придумувати все з нуля і дозволяє більш ефективно використовувати код повторно;
• Модулі для вирішення завдань «першої необхідності», що дозволяють почати розробку з порожнього місця, не винаходячи нічого свого.

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

CMF і CMS

Розглядаючи поняття framework-системи, не можна обійти стороною, поняття системи управління контентом. Дуже часто поняття CMF (Content Management Framework) плутають з поняттям CMS (Content Management System). Це невірно, тому що це принципово різні речі.

CMF-системи не можна порівнювати з CMS-системами! Це головне правило, яке дуже часто порушують розробники при обговоренні питань пов'язаних з розробкою та використанням CMF-систем. CMF і CMS різні поняття, незважаючи на їх схожість.

CMS-система - це набір модулів для швидкого створення сайтів. На відміну від CMF, CMS-система - це є завершений продукт, який орієнтований, в першу чергу, не на програмістів, а на користувачів не знайомих з премудростями створення інтернет-додатків. CMS-система (дуже часто її називають «движок сайту») дозволяє за лічені години створити сайт або портал який складається з обмеженого набору готових модулів (новини, гостьова книга, форум). В більшості своїй, CMS-системи створюються без урахування їх подальшого зростання. Підсумок - відсутність жорсткої внутрішньої архітектури системи. Це істотно ускладнює процес супроводження проекту.

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

Вищесказане відноситься до «чистих» CMS-систем. Тобто до CMS-систем, які написані з нуля на порожньому місці. На щастя, ніхто не заважає використовувати вигоди обох типів систем. Останнім часом в Інтернеті почали з'являтися CMF / CMS-системи. Ці системи являють собою CMS-систему, створену на фундаменті framework'а. Вигоди очевидні. Детермінована внутрішня архітектура, яка в більшості випадків документована і розвинені механізми абстракції, які не залежать від CMS-утворюючих модулів. Супроводжувати проект, створений на основі CMF / CMS-системи, на порядок простіше, ніж проект, створений на основі «чистої» CMS-системи. Це пояснюється тим, що в першому випадку, при створенні CMS-системи, програмістам доводиться виконувати ряд вимог, які диктує framework. Завдяки цьому CMS-система набуває яскраво виражену архітектуру, як і всі додатки створюються за допомогою CMF-системи.

Якщо CMS-система являє собою закінчений продукт, то CMF-система - це набір інструментів, за допомогою яких, можна створити абсолютно будь-який продукт, зокрема і CMS-систему. Так як framework-система - це набір інструментів, то для її використання потрібні програмісти, які можуть з цими інструментами працювати. З цим пов'язаний ще один момент, характерний для CMF - навчання персоналу для роботи з CMF-системою.

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

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

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

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

Питання архітектури дуже складні за своєю суттю, і навіть багато фахівців не можуть сказати за п'ять хвилин нічого зрозумілого із приводу якихось конкретних рішень. Але, незважаючи на таку велику контекстну залежність архітектури від типу додатка, існують добре вивчені і перевірені варіанти вирішення архітектурних проблем. Ці варіанти рішення носять назву «шаблони проектування» (Design Patterns). У тому чи іншому вигляді шаблони проектування можуть бути застосовані у всіх додатках. Виявлення оптимальних реалізацій шаблонів становить невід'ємну частину роботи над framework-системою (я б сказав, що справжня framework-система просякнута духом патернів проектування).

Шаблони проектування існують для всіх основних типів завдань, що виконуються CMF-системою. Рішення цих завдань вимагають продуманої стандартизації (зрозуміло, в рамках проекту). Таких завдань декілька:
• Обробка запиту ІС 1);
• Організація предметної області ІВ;
• Організація подання ІС;
• Організація допоміжних підсистем;

Завдання, які я виділив, занадто умовні, що б вважати їх формальним списком завдань framework-системи. Цей список наведений, що б Ви могли зрозуміти, в яких напрямках розробники концентрують свої зусилля.

Обробка запиту

Підсистема обробки запиту зіставляє запит клієнта з дією, що виконується системою. Запити до системи можуть бути досить «різношерстими». Вони відрізняються як по вигляду, так і за смисловим навантаженням. Це залежить від типу додатка. Самі механізми зіставлення і їх дії можуть змінюватися під час супроводження проекту. Ці вимоги диктують розробникам CMF-системи необхідність створення зручного механізму аналізу та обробки запитів. У разі якщо розробники справляються зі своїм завданням, то додатки, побудовані на базі їх framework-системи, будуть красивими і легко запам'ятовуються адресами кшталт «http://www.server.com/news/2005-02-03» замість «http: / / www.server.com/index.php?module=news&action=show&date=2005-02-03». Безумовно, краса запиту не єдине якість, якого домагаються розробники. Гнучкі механізми зіставлення запиту з дією грають дуже важливу роль, так це дуже зміна частина системи.

Організація подання

Уявлення - це підсистема відображення даних. З її допомогою логіка предметної області відокремлюється від логіки відображення даних. Уявлення - це найстабільніша частина інформаційної системи. Відображення даних може мінятися дуже часто, на відміну від самих даних і методів їх обробки. Тому framework-система повинна надати зручні та гнучкі механізми роботи з логікою відображення. Для вирішення цього завдання використовуються шаблонні системи, чиє завдання полягає у відділенні логіки відображення і укладання її в окремі файли (шаблони відображення), які можна редагувати окремо від усіх інших частин системи. Завдяки цьому, роботу над проектом можна ефективно розпаралелити (Організація предметної області → програміст + адміністратор БД, Організація подання → верстальник + дизайнер).

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

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

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

Якщо ви написали код, який можна використовувати повторно, але він не вписується в вашу бібліотеку, створіть нову.

Тримайте свою базу бібліотек [репозиторій]

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

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

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

Файли, що включаються

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

Файли, що включаються можуть містити будь-який код XHTML або PHP і зазвичай зберігаються з розширенням. Inc, хоча можна використовувати також розширення. Php,. Txt, або. Htm. Вміст файлу, що включається кодується один раз і включається в будь-яку необхідну кількість сторінок PHP. Якщо під файлом, що включається робиться зміна, то оновлення автоматично відбивається на всіх сторінках PHP, які посилаються на цей файл.

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

Header.inc
<h3> Welcome to WebBooks.Com </ h3>
Цей приклад показує файл, що включається з ім'ям header.inc. Файл містить текст "Welcome to WebBooks.Com", оточений тегом XHTML <h3>. Він створює заголовок третього рівня, який можна тепер включати на всі сторінки, які складають сайт WebBooks. Після створення файлу, що включається, його можна включити в сторінку PHP за допомогою однієї з наступних функцій:
require (ім'я_файлу) - включає і перевіряє вказаний файл
include (ім'я_файлу) - інший спосіб підключення файлів

У наступному прикладі файл header.inc включається в існуючу сторінку PHP:
home.php
<? Php
require ('header.inc');
echo "<p> This is the WebBooks site...</ p>";
?>

Функція require () викликає файл header.inc і перевіряє вміст файлу. Вміст потім виводиться, так ніби воно було частиною сторінки home.php. У цьому прикладі функція require () кодується вгорі сторінки, так як вона містить інформацію заголовка. Оператор require () можна, однак, включити в будь-якому місці документа PHP. Розташування функції require () визначає, де буде виводитися вміст файлу в контексті сторінки PHP.
Welcome to WebBooks.Com
This is the WebBooks site...

Важливо відзначити, що при використанні файлів, що включаються, які містять конфіденційну інформацію, таку, як паролі або інформацію про користувача, файли повинні зберігатися з використанням розширення. Php, а не. Inc або іншого нестандартного розширення. Файли, які застосовують нестандартні розширення файлів, можуть завантажуватися з сервера Web, а їх вміст можна переглядати як звичайний текст. Використання розширення. Php гарантує, що клієнт не зможе побачити вихідний код, сервер поверне тільки код XHTML.

Використання функцій
Функції використовуються для розбиття великих блоків коду на менші, більш керовані одиниці. Міститься всередині функції код виконує певне завдання і повертає значення. PHP містить два типи функцій - визначені користувачем (або створені програмістом) і внутрішні (вбудовані функції), які є частиною визначення мови PHP. Цей розділ присвячений створенню та застосуванню певних функцій користувача.
Певні функції користувача створюються за допомогою ключового слова function. Вони особливо корисні у великих програмах PHP, так як можуть містити блоки коду, які можуть викликатися чи використовуватися в програмі, що дозволяє уникнути повторного переписування коду. Далі представлений приклад простої визначеної користувачем функції PHP:
function AddNumbers ($ num1, $ num2)
{

echo "Це приклад функції PHP. Вона обчислює суму двох чисел і повертає
результат, що викликається у програмі ";

 

return $ num1 + $ num2;

 

}

Певні функції користувача можуть викликатися в будь-якому місці блоку коду PHP. У PHP функція виконується при використанні в коді її імені. Після виклику функція отримує всі передані їй значення у формі параметрів, виконує певні завдання і повертає значення, що викликає програма. Простий приклад показаний нижче.
<? Php
function AddNumbers ($ num1, $ num2)

 

{
return $ num1 + $ num2;
}
echo "Сума 5 і 2 дорівнює". AddNumbers (5,2);
?>
Проте певна на початку функція AddNumbers () викликається тільки пізніше в програмі. Виклик функції відбувається в операторі echo. Виводиться рядок "Сума 5 і 2 дорівнює". Ім'я функції з'єднується з рядком виведення, викликаючи тим самим функцію. Для функції передається два параметри - 5 і 2. Вони присвоюються параметрами функції $ num1 і $ num2. Параметри складаються, і викликається оператор return, щоб "повернути" значення або суму двох чисел в те місце в блоці коду PHP, який спочатку викликав функцію. Висновок результату показаний нижче:
Сума 5 і 2 дорівнює 7
Імена функцій слідують тим же правилам, що і змінні у PHP. Допустимі імена можуть починатися з букви або підкреслення, після чого може слідувати будь-які літери, цифри або підкреслення.

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

Загальні відомості

В якості основи проектування інформаційних систем застосовуються "типові рішення" або "шаблони проектування" (Patterns).

Шаблони проектування (патерн, design pattern) - це багато разів застосовувана архітектурна конструкція, що надає рішення для загальної проблеми проектування в рамках конкретного контексту й описує значимість цього рішення.

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

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

У 1987 році Кент Бек і Вард Каннігем взяли ідеї Олександра та розробили шаблони відповідно до розробки програмного забезпечення для розробки графічних оболонок мовою Smalltalk.

У 1988 році Ерік Гамма почав писати докторську дисертацію при Цюріхському університеті про загальну переносимість цієї методики на розробку програм.

У 1989-1991 роках Джеймс Коплін трудився над розробкою ідіом для програмування на C + + та опублікував у 1991 році книгу Advanced C + + Idioms. У цьому ж році Ерік Гамма закінчує свою докторську дисертацію і переїжджає до США, де у співробітництві з Річардом Хелмом, Ральфом Джонсоном і Джоном Вліссідсом публікує книгу Design Patterns - Elements of Reusable Object-Oriented Software. У цій книзі описані 23 шаблона проектування. Також команда авторів цієї книги відома громадськості під назвою Банда чотирьох (Gang of Four, часто скорочується до GoF). Саме ця книга стала причиною зростання популярності шаблонів проектування.

Іншим видатним діячем у галузі проектування програмних систем, який підтримав використання патернів, є Мартін Фаулер, який написав книгу "Архітектура корпоративних програмних додатків" (Patterns of Enterprise Application Architecture). Як зазначив Мартін Фаулер у своїй книзі "збираючись скористатися типовими рішеннями, не забувайте, що вони тільки відправна точка, а не пункт призначення".

У книзі Крейга Лармана "Застосування UML і шаблонів проектування" описано 9 шаблонів GRASP (General Responsibility Assignment Software Patterns, загальні зразки розподілу обов'язків) - патернів, використовуваних в об'єктно-орієнтованому проектуванні для вирішення спільних завдань за призначенням обов'язків класам і об'єктам. Кожен з них допомагає розв'язати певну проблему, що виникає при об'єктно-орієнтованому аналізі, і яка виникає практично в будь-якому проекті з розробки програмного забезпечення.

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

Правильно сформульований шаблон проектування дозволяє, відшукавши вдале рішення, користуватися ним знову і знову.

Однак іноді шаблони консервують громіздку і малоефективну систему понять, розроблену вузькою групою. Коли кількість шаблонів зростає, перевищуючи критичну складність, виконавці починають ігнорувати шаблони і всю систему, з ними пов'язану. Нерідко шаблонами замінюється відсутність або недоліки документації, яка складна програмному середовищі.

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

 

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

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

Огляд

Область комп'ютерних наук з моменту свого утворення зіткнулася з проблемами, пов'язаними зі складністю програмних систем. Раніше проблеми складності вирішувалися розробниками шляхом правильного вибору структур даних, розробки алгоритмів та застосування концепції розмежування повноважень. Хоча термін "архітектура програмного забезпечення" є відносно новим для індустрії розробки ПЗ, фундаментальні принципи цієї області невпорядковано застосовувалися піонерами розробки ПЗ починаючи з середини 1980-х. Перші спроби усвідомити і пояснити програмну архітектуру системи були повні неточностей і страждали від нестачі організованості, часто це була просто діаграма з блоків, сполучених лініями. У 1990-ті роки спостерігається спроба визначити і систематизувати основні аспекти даної дисципліни. Початковий набір шаблонів проектування, стилів дизайну, передового досвіду (best-practices), мов опису та формальна логіка були розроблені протягом цього часу.

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

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

Підсумок

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

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

Добре, ми з'ясували що архітектура це дуже важливий аспект розробки. Але що ж це таке? У контексті PHP5 додатки з упором в парадигму - це ієрархія класів, інтерфейси та схеми їх взаємодії.

Вибір або створення архітектури залежить від конкретних завдань. Наприклад, наскільки універсальним планується додаток, які модулі повинні бути присутніми, яка запланована навантаження на ресурс.

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

Якість архітектури

Ознаки загниваючого проекту

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

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

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

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

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

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

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

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