Архітектурні компроміси

Марк Річардс

Кожен архітектор програмного забезпечення повинен знати і розуміти, що не можна отримати все відразу На практиці неможливо спроектувати архітектуру, одночасно володіє високою продуктивністю, високою доступністю, високим рівнем безпеки і високим рівнем абстракції Існує одна реальна історія, яку архітектори програмного забезпечення повинні знати, розуміти і розповідати своїм клієнтам і колегам Я маю на увазі історію корабля «Ваза»

У 1620 році йшла війна між Швецією і Польщею Бажаючи швидше завершити цю дорогу війну, король Швеції наказав побудувати галеон, який називався «Ваза» Це був незвичайний корабель Вимоги до нього були не схожі на вимоги до будь-якого іншого кораблю того часу Він повинен був мати довжину більше 60 метрів, нести 64 гармати на двох батарейних палубах, а також брати на борт 300 солдатів за раз для безпечної доставки до Польщі по морю Час підтискав, грошей не вистачало (звучить знайомо, так) Займався цим судном кораблебудівник ще ніколи не проектував такі кораблі Він спеціалізувався на менших, однопалубних судах Проте він взявся за проектування і споруду «Вази», покладаючись на свій колишній досвід У результаті корабель, відповідний цим специфікаціям, був побудований Настав день спуску на воду Корабель гордо виплив у гавань, відсалютував з усіх гармат .. і слідом за тим затонув

Проблема «Вази» була очевидною кожен, хто хоч раз бачив палубу великого бойового корабля XVII століття, знає, що палуби таких кораблів були переповнені і небезпечні, особливо під час битви Споруда корабля, який служив би одночасно бойовим і транспортним, було дорогої помилкою Кораблебудівник, прагнучи виконати всі побажання короля, створив нестійке і погано збалансоване судно

Архітектор ПЗ може почерпнути з цієї історії багато корисного і врахувати цей сумний досвід при проектуванні архітектури програмних продуктів Спроба виконати всі вимоги відразу (як у випадку з «Вазою») створює нестійку архітектуру, яка не вирішує толком ні одну з поставлених завдань Хороший приклад такого роду – вимога змусити сервіс-орієнтовану архітектуру (SOA, service-oriented architecture) заодно функціонувати як рішення «точка-точка» Зазвичай це змушує обходити різні рівні абстракції, створювані підходом SOA, і в результаті виникає архітектура, що нагадує блюдо спагетті з італійського ресторану У розпорядженні архітектора є кілька інструментів для визначення тих компромісів, на які доводиться йти при проектуванні архітектур Два популярних методу такого роду – Атамась (Architecture Tradeoff Analysis Method) і CBAM (Cost Benefit Analysis Method) Додаткову інформацію про Атамась та Свамі можна знайти на сайті SEI (Software Engineering Institute)

Біографія автора наведена на сторінці 23

Джерело: Форд Н, Найгард М, де Ора Б, 97 етюдів для архітекторів програмних систем – Пер з англ – СПб: Сим-вол-Плюс, 2010 – 224 с, Мул

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*