Как говорилось ранее, архитектору постоянно приходится принимать компромиссные решения. Для заданного набора функциональных и качественных требований не существует единственно правильной архитектуры, единственного «верного решения». По своему опыту мы знаем, что перед тем как тратить деньги на построение, тестирование и развертывание системы, необходимо оценить архитектуру и определить, удовлетворяет ли она поставленным требованиям. Оценка пытается спрогнозировать выполнение концептуальных требований, упоминавшихся в предыдущих разделах (или специфических для конкретной системы).
Существует два стандартных подхода к оценке архитектуры (Clements, Kazman, and Klein 2002). В методах первой категории определяются свойства архитектуры, часто посредством моделирования или имитации одного или нескольких аспектов. Например, на базе проведенного моделирования производительности оценивается пропускная способность и масштабируемость системы, а модель дерева отказов используется для оценки надежности и доступности. В моделях других типов метрики сложности и привязки используются для оценки способности к изменениям и удобства сопровождения.
Во второй (самой широкой) категории методов оценки архитектура оценивается по результатам опроса архитекторов. Методы структурного опроса весьма многочисленны. Например, в процессе SARB (Software Architecture Review Board), разработанном в Bell Labs, к оценке привлекаются эксперты, работающие в организации и обладающие глубокими познаниями в области телекоммуникаций и смежных областях (Maranzano et al. 2005).
В другом методе опроса – АТАМ (Architecture Trade-off Analysis Method) (Clements, Kazman, and Klein 2002) – оцениваются риски того, что архитектура не удовлетворяет концептуальным требованиям. В АТАМ используются сценарии, каждый из которых описывает концептуальное требование одной из заинтересованных сторон к системе. Затем архитекторы объясняют, как архитектура поддерживает каждый из сценариев.
No related posts.