Архітектура та проектування програмного забезпечення 1 ТЕМА 1. ВСТУП ДО АРХІТЕКТЕКТУРИ ПРОГРАМ Протягом десятиліть розробники програмного забезпечення створювали свої проекти або з нуля, або використовуючи вже накопичений досвід, якщо такою якось вдавалося придбати. М теперішній час інтенсивно розвивається дисципліна програмної архітектури і проекту вання. Тепер ми можемо говорити про архітектуру високого рівня і архітектуру низького рівня в термінах, зрозумілих усім професійним розробникам. Точно так, як і ми захоплюємося такими інженерними розробками, як тунель між Великобританією і Францією або про ект Міжнародної космічної станції, незабаром ми захоплюватимемося грандіозною програмною архітектурою. План Архітектура та проектування програмного забезпечення 2 1.1 Огляд технологій розробки 1.2 Поняття архітектури програми 1.3 Цілі вибору архітектури програмного забезпечення 1.4 Декомпозиція проетку Лі тература: [1] – Браунде Э. Технология разработки программного обеспечения. – СПб.: Питер, 2004. – C. 359 - 366 [2] – Орлов С.А. Технологии разработки программного обеспечения. (Разработка сложных программных систем):учеб. пособие. - СПб.:Питер. - 2002. - 464с. - (ил .). - Учебник для вузов. - 5 - 94723 - 145 - Х. – C. 362 - 370 1.1 Огляд технології розробки Будь - яке застосування має апаратні і програмні компоненти. Як приклад розглянемо антиблокувальну систему автомобільних гальм. Вона має механічну, електронну і програмну склад ові і покликана збільшити ефективність гальмування, не допускаючи блокування коліс. Іншим прикладом може служити інтерактивний чат в Мережі. Системна розробка - це процес аналізу і проектування, який розділяє застосування на апаратні і програмні компоненти Деякі аспекти цієї декомпозиції диктуються вимогами замовника, інші визначаються розробниками. Розглянемо процес декомпозиції на прикладі можливої конфігурації інтернет - версії гри Зустріч, GameCorp ( рис 2), що запускається на сервері. Процес системної розробки починається з визначення загальних системних вимог. Потім робиться вибір оптимального співвідношення між апаратним і програмним забезпеченням. Після цього визначається Архітектура та проектування програмного забезпечення 3 декомпозиція застосування на апаратне і програмне забезпечення . Потім до програмної частини застосовується технологія розробки, починаючи з аналізу вимог і т. д.. Ми розглядатимемо проекти з очевидним розподілом на апаратне і програмне забезпечення, подібні до гри Зустріч. У цьому прикладі система фізично розділена н а комп'ютери гравців, ігровий сервер і сервер обробки рахунків ( рис 2). Компоненти програмного забезпечення розподілені між комп'ютерами гак. як показано на рис . 2. Вбудоване програмне забезпечення взаємодіє на мікросекундному рівні не з технічними засобами, що знаходяться у іншому місці. Наприклад, програмне забезпечення такого роду містить гальмівна система з автоматичним антиблокуванням (мал. 5.3). Інтернет - орієнто вану версію гри Зустріч (мал. 5.2), навпаки, не можна розглядати як вбудоване програмне забезпечення. Вбудовані застосування ставлять одне з найскладніших завдань перед розробником, оскільки для них дуже велике Архітектура та проектування програмного забезпечення 4 значення має час реакції. Міністерство оборон и США досить давно використовує передові ме - тоды системної розробки, оскільки військові системи вимагають дуже тісної інтеграції програмного забезпечення і технічних засобів. Підрядчики міністерства оборони використовують величезну кількість системних розр обників Ці розробники формують системні вимоги і проводять дослідження, необхідні для створення відповідної конфігурації. Норми для системних розробників визначаються в документах IEEE і інших стандартах, таких як IEEE P1233. Цей стандарт містить широкий с пектр угод по таких питанням, як розмір і вага механічних компонентів, обмеження ресурсів, обмеження середовища, продуктивність, функціональність, сумісність, надійність, умови супроводу і технологічність виробництва. 1.2 Поняття архітектури програми Архітектура та проектування програмного забезпечення 5 Як що порівнювати розробку програм з процесом спорудження моста, то аналіз вимог буде аналогічний вибору місць, де міст починатиметься і закінчуватиметься, а також визначенню роду навантажень, які він повинен витримувати. Далі, архітектор моста повинен виріши ти, яким буде міст: підвісним, консольним або деякого іншого типу, що задовольняє вимогам. Іншими словами, він повинен буде визначити архітектуру моста. Розробники програмного забезпечення стикаються з схожим вибором. У цій темі ми розглядаємо вибір архіте ктури для застосування. Створення архітектури - ЦЕ проектування па найвищому рівні. Іншу частину процесу проектування ми називатимемо детальним проектуванням. Ясний опис архітектури дуже важливий для усіх застосувань і обов’язково у тому випадку, коли до р озробки притягується велика кількість людей. Причиною цього служить необхідність розбиття усього застосування на частини (модулі) з їх наступною зборкою. Вибір архітектури забезпечує необхідну модульність. Розробники, яким доручається створення архітектури (технічні архітектори), зазвичай є найдосвідченішими в команді розробки. 1.3 Цілі вибору архітектури програмного забезпечення Для конкретного проекту розробки програмного забезпечення може бути декілька відповідної архітектури, з якої необхідно вибрати к ращу. Зазвичай буває складно задовольнити усі вимоги, оскільки архітектура може виконувати одну з вимог і не виконувати інше. З цієї причини усім вимогам необхідно присвоїти пріоритети. Наведемо приклад списку основних цілей розробки. ♦ Розширення. Полегше ння додавання нових властивостей. ♦ Зміни. Архітектура та проектування програмного забезпечення 6 Полегшення зміни вимозі. ♦ Простота: ♦ простота розуміння; - простота реалізації. ♦ Ефективність: * * досягнення високої швидкості : виконання і (чи) компіляції; ♦ досягнення малого розміру : об'єктного коду і (чи) початкового кілка. Розширення визначає міру, в якій архітектура повинна підтримувати додавання нових можливостей в застосування. Найчастіше чим краще архи - тектура пристосована до розширення, тим більше скл адну структуру вона має і більше часу вимагається на розробку. Розширюваність зазвичай вимагає введе - ния вищих абстракції в процес. Наприклад, ми можемо побажати, щоб архітектура нашої відеогри Зустріч підтримувала не лише цю гру (нижній рівень універсальн ості), але і взагалі будь - яку ролеву відеогру. Универсаль - ность дає безліч переваг, але її реалізація вимагає великих витрат часу. Одним з важливих завдань при виборі міри універсальності є визначення класу можливих розширень. Ми не можемо проектувати в ра с - чете на усі можливі розширення. У зв'язку з цим дуже корисні необязатель - ные і бажані вимоги, оскільки вони показують, в яку сторону бу - дет спрямований розвиток застосування. Розробка з розрахунком на зміни переслідує інші цілі, хоча має на увазі застосу вання тих же прийомів проектування, що і для забезпечення розширюваності. В даному випадку ми хочемо спроектувати архітектуру таким чином, щоб вона допускала зміну вимог, наприклад щоб вимогу "гравець повинен постійно мати повний контроль над своїм персона жем" можна було замінити вимогою "гравець час від часу випадковим чином втрачає контроль над своїм персонажем". Архітектура та проектування програмного забезпечення 7 Простота є метою проектування за будь - яких обставин. Проста архітектура, яка допускає розширення і зміни, є рідкістю, і її створення вимагає вел иких зусиль До інших критеріїв, використовуваних при виборі архітектури, відносяться заощадження машинного часу і економія пам'яті. 1.4 Декомпозиція проекту Після невеликої практики досить просто створювати маленькі програми. Великі застосування, проте, с тавлять перед розробниками дуже важкі задачі, рішення яких досить важко досягається на практиці. Принципова проблема систем програмного забезпечення - це їх складність. Складність не у сенсі кількості рядків коду, а в сенсі їх взаємозв'язку. Дуже хороший с посіб боротьби із складністю - ' розбиття завдання на півзавдання, характерні властивості невеликих програм, що мають. З цієї причини декомпозиція (чи мо - дуляризация) є проблемою критичної важливості і одним з самих цікавих етапів розробки. Розробник насамп еред повинен уявити, як застосування працюватиме на вищому рівні, а потім розробити декомпозицію, відповідну ментальній моделі. Наприклад, які чотири або п'ять модулів будуть реалізовано в грі Зустріч? Чи на п'ять або на шість модулів розбити персональне ф інансове застосування? Наступна проблема, яка встає перед розробником, - це декомпозиція вже отриманих компонентів, і т. д. Цей процес іноді називають рекурсивним проектуванням. Почнемо з цілей декомпозиції. Зв'язність усередині модуля - це сила взаємозв'я зків між елементами модуля. Зчеплення характеризує міру взаємодії модуля з іншими модулями. Ефективна модульність досягається максимізацією зв'язності і мінімізацією зчеплення. Такий спосіб дає можливість розбивати складні завдання на простіші. Застосуванн я цього підходу до проекту моста ілюструє рис . 4. Архітектура та проектування програмного забезпечення 8 Шість компонентів, отриманих при декомпозиції моста, демонструють велику міру зв'язності, зчеплення ж між ними дуже мале. Частини (наприклад, цегла) кожного компонента моста (наприклад, опори) взаємозалеж ні, тобто зв'язність усередині кожного компонента висока. З іншого боку, кожен компонент залежить тільки від декількох сусідніх компонентів, тобто зчеплення між ними досить низьке. Наприклад, опора зв’язана тільки з ДВОМА горизонтальними блоками моста. Віз ьмемо інший приклад залізну ферму (див. рис. 4). Тут усі компоненти мають одну загальну точку. і отже, зчеплення між цими компонентами дуже високе. Мале зчеплення в сукупності з великою зв'язністю дуже важливі при проектуванні застосувань зважаючи на постійний процес внесення змін в проекти. Порівнянний життєвий цикл застосування і моста. Зміни в Архітектура та проектування програмного забезпечення 9 застосуванні але багато разів вірогідніші, ніж в констр укції моста. Архітектура з малим зчепленням і великою зв'язністю більше пристосована для модифікації, оскільки зміни в такій архітектурі мають найбільш локальний ефект. Проте створювати таку архітектуру досить складно. Кількість модулів високого рівня має бути невелика. Звичайна рекомендована кількість (норматив) - 7±2, але через специфіку деяких проектів це число може сильно варіюватися. Різниця між дрібномасштабними і великомасштабними проектами вимірюється кількістю рівнів вкладення в модулях. У великома сштабних застосуваннях модулі високого рівня розбиваються на підмодулі, ті у свою чергу розбиваються на під - підмодулі і т. д. Норматив 7±2 застосовується для кожної такої декомпозиції. Як приклад розглянемо декомпозицію гри Зустріч. Один варіант - розбити усі частини гри на чотири модулі. ♦ Довкілля, в якому відбувається дія гри (зони, з’єднання і т. д.). ♦ Механізм управління грою (лічильники, реакції на події і т. д.). ♦ Учасники гри (персонаж гравця, інші персонажі і т. д.). ♦ Артефакти, задіяні в грі (мечі, книги, щити і т. д. - вони з’являться в майбутніх версіях гри). Усі ці модулі мають достатню зв'язність. Наприклад, герої гри вистачає інтенсивно взаємодіють між собою. З іншого боку, зчеплення цих модулів сильніше, ніж нам би хотілося. Наприклад, при зустрічі персонажів задіються і довкілля, і механізми управління, і самі персонажі, і артефакти. У якості іншою прикладу розглянемо декомпозицію персонального фінансового застосування. ♦ Рахунки (перевірка, збереження і т. д.). ♦ Оп лата рахунків (електронна, чеком і т. д.). Архітектура та проектування програмного забезпечення 10 ♦ Глобальні звіти (загальні активи, заборгованість і т. д.). ♦ Позики (автомобіль, освіта, будинок і т. д,). ♦ Інвестиції (акції, боргові зобов'язання і т. д.). Хоча ця декомпозиція приваблива з точки зору користувача, вона має великі недоліки як архітектурна декомпозиція. Наприклад, рахунки мають малу зв'язність, оскільки вони слабо взаємозв'язані. А зв'язність модулів тут досить велика. Наприклад, при виплаті заборгованості задіються рахунки, оплата рахунків, позики і, можливо, звіти. Існує наступна альтернатива цієї декомпозиції. ♦ Інтерфейс (призначений для користувача інтерфейс, комунікаційний інтерфейс, звітність і т. д.). ♦ Постачальники (орендодавець, позики, комунальні послуги і так далі). ♦ Активи (перевірка рахункі в, акції, боргові зобов'язання і т. д.). Досконала архітектура - мета гідна, але важкодосяжна. Програмування - це не єдина область інженерії, в якій складно отримати бездоганну модульність. У [ 1] Шнаерсон показав, що, незважаючи на усі спроби General Moto rs розбити на модулі проект свого першого електричного автомобіля, чинники відповідності <норми (вимоги відповідності деталей автомобіля обмеженому простору) породжували високий рівень зчеплення між компонентами. Підведемо підсумки цього розділу. ОДИН ІЗ СПОСОБІВ ПОЧАТИ ВИБІР БАЗОВОЇ АРХІТЕКТУРИ 1. Розробити ментальну модель застосування на високому рівні, начебто це було маленьке застосування. Наприклад, персональне фінансове Архітектура та проектування програмного забезпечення 11 застосування отримує або видає гроші у будь - якому порядку під управлінням інтерфейсу користувача. 2. Виконати декомпозицію на необхідні компоненти. Пошук високої зв'язності і низ - кого зчеплення. Зокрема, для персонального фінансового застосування виконується декомпозиція на Активи. Постачальники і Інтерфейс. 3. Повторити цей процес дл я компонентів Список вже відомої архітектури приведений далі в цій главі. Деталі Ця частина глави може бути повністю освоєна посту прочитання наступних глав. Проте розуміння основної ідеї цієї частини потрібне для виробництва якісних програмних продуктів.