Перевіряйте рішення на міцність за ключовими характеристиками

Стівен Джонс

Спочатку архітектура додатку Формується на підставі заданих бізнес-вимог, обраних або вже застосовуваних технологій, діапазону продуктивності, очікуваних обсягів даних і фінансових ресурсів, виділених для побудови, розгортання та управління системою Рішення, яким би воно не було, має відповідати вимогам з цього набору або перевершувати їх – і при цьому успішно працювати в сучасних умовах (інакше це попросту не вирішення)

Тепер візьміть своє рішення і подивіться, які проблеми зявляться, якщо «розтягнути» ключові характеристики

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

«Розтягування» ключових характеристик допоможе вам:

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

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

• Переконатися в тому, що механізми доступу до даних залишаться працездатними при масштабування системи Рішення, що працює з тижневим обсягом даних, може не впоратися з обсягом, накопиченим за півроку

• Перевірити, як при підвищенні робочого навантаження додаток розподілить її на додаткове обладнання (якщо воно буде потрібно), і проаналізувати шляхи переходу при підвищенні навантаження Аналіз перехідних шляхів перед розгортанням додатка може вплинути на механізми зберігання даних і їх структуру

• Переконатися, що додаток зможе нормально відновлюватися після збоїв при зростанні обсягу даних і / або поділі даних в межах розширеної інфраструктури

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

Стівен Джонс (Stephen Jones) проектує рішення для Tier-lTelco Billing і супутні великомасштабні процеси для таких компаній, як Telstra і Optus (Австралія), а також AT & T (США) Зокрема, він займався вихідної реалізацією систем тарифікації Telco, перепроектування системи опротестування рахунків і боротьби з фальсифікаціями і більше двох років управляв службою цілодобової підтримки Telstra

Джерело: Форд Н, Найгард М, де Ора Б, 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>

*

*