11.5. Заключение

АТАМ зарекомендовал себя как надежный метод оценки программной архитек­туры. Он подразумевает формулирование (в форме сценариев) ответственными за проект и заинтересованными лицами точного перечня требований по атрибу­там качества и исследование архитектурных решений, значимых в контексте реа­лизации всех высокоприоритетных сценариев. Путем разделения такого рода ре­шений на рискованные и нерискованные оценщикам удается выявить проблемные участки рассматриваемой архитектуры.

Одного лишь знания принципов, на которых основывается метод АТАМ, не­достаточно. Важно понимать, для каких целей он не предназначен.

• АТАМ не предусматривает оценки требований. Другими словами, по ре­зультатам оценки, проведенной этим методом, нельзя судить о перспекти­вах реализации всех предъявленных к системе требований. Он лишь помогает понять, удастся ли при данном проектном решении реализовать основные требования.

• АТАМ не предоставляет возможности оценки кода. Поскольку оценка по этому методу проводится на ранних стадиях жизненного цикла, никаких допущений относительно существования кода не делается, а средств ин­спекции кода не предусматривается.

• АТАМ не связан с фактическим тестированием системы. Так как, опять же, оценка АТАМ проводится на раннем этапе жизненного цикла, допущения о существовании системы и средств фактического тестирования в рассмат­риваемый метод не заложены.

• Не являясь точным инструментом, АТАМ выделяет в рамках архитектуры потенциальные области риска. Выражаются они в виде точек чувствитель­ности и точек компромиссов. Поскольку АТАМ основывается на знаниях архитектора, некоторые риски могут так и остаться неустановленными. Те же риски, которые удается выявить, в рамках АТАМ не подлежат количе­ственной оценке. Другими словами, оценщики не делают выводов об убыт­ках, которые могут последовать по причине неустранения топ или иной точки чувствительности. Финансовые аспекты рассматриваются в главе 12 в связи с методом анализа стоимости и эффективности (cost benefit analysis method, СВАМ).

Опенок, проведенных по методу АТАМ, на нашем счету множество; нам также доводилось наблюдать за тем, как их выполняют другие специалисты, и даже проводить посвященные этому методу занятия. Практически в каждом из этих случаев мы сталкивались с одной и той же реакцией со стороны технических специалистов — они крайне удивлялись, узнав, что за относительно короткое время можно выявить немалое количество рисков. Ответственным лицам удавалось понять, почему реализации поставленных коммерческих задач препятствуют те или иные технические проблемы. Итак, АТАМ оказался весьма полезной штукой.

6. Дополнительная литература

В то время, когда книгу, которую вы держите в руках, готовили к печати, мы занимались выверкой начального варианта учебного курса но АТАМ. Подробно­сти этого предприятия изложены на веб-сайте анализа компромиссных архитек­турных решений на сервере Института программной инженерии — http://www.sei. cmu.edu/ata/ata-init.html. Более подробное исследование АТАМ, сопровождаемое конкретным примером оценки спутниковой системы данных NASA, приводится в работе [Clements 02а].

Довольно необычно требования по атрибутам качества и их связь с проектны­ми решениями трактуются в публикации [Chung 00]. В частности, в ней дается ссылка на издание [Boehm 76]. Описанное в нем дерево характеристик качества программных продуктов во многом схоже с деревьями полезности, применяемы­ми в рамках АТАМ.

Если вам интересны исторические предпосылки возникновения АТАМ и при этом вы не прочь ознакомиться со вторым (более простым) методом архитектур­ной оценки, прочитайте работу [Kazman 94], посвященную методу анализа про­граммной архитектуры (software architecture analysis method, SAAM).