АНАЛИЗ АРХИТЕКТУРЫ

В результате анализа архитектурно-экономического цикла мы подошли к этапу, на котором в распоряжении архитектора имеется спроектированная и докумен­тированная архитектура. Логически это подводит нас к проблеме оценки и ана­лиза архитектуры — тех действий, по результатам которых принимается решение об адекватности или неадекватности выработанного решения поставленной зада­че. Именно об этом пойдет речь в третьей части книги, предварить которую, по нашему мнению, следует ответами на ряд вопросов об архитектурной оценке: зачем нужно ее проводить, когда это необходимо делать, каковы связанные с ней затраты (стоимость) и выгоды, следует ли ее планировать, какие требуются пред­варительные условия и что должны собой представлять ее результаты.

Зачем?

У любой архитектуры есть одно замечательное качество — она содержит сведе­ния о наиважнейших свойствах системы, даже если эта система еще не существу­ет. Принимая проектные решения, архитекторы отталкиваются от известных и предсказуемых нисходящих последствий, проявляющихся в ходе конструиро­вания систем(ы). Без этого толку от процесса создания архитектуры было бы не больше, чем от кидания костей. Мы бы выбирали произвольную архитектуру, строили на ее основе систему, проверяли, реализовались ли в ней требуемые свой­ства, и, не встретив таковых, возвращались к началу. Готовых рецептов по проек­тированию архитектуры никто еще не придумал, но в том, что методология про­двинулась гораздо дальше примитивного угадывания, можно не сомневаться.

В общем и целом, архитекторы представляют себе последствия принимаемых решений. На материале главы 5 мы можем сделать вывод о том, что архитектур­ные тактики и образцы наделяют системы известными свойствами. Следователь­но, проектные альтернативы — другими словами, варианты архитектуры — под­даются анализу. Располагая архитектурой, можно делать выводы о системе - даже если до ее создания дело еще не дошло.

Так зачем же архитектуру нужно оценивать? Во-первых, от нее слишком мно­гое зависит, а во-вторых, ничто не мешает вам это сделать. Эффективная методи­ка оценки предполагаемой архитектуры, позволяющая сделать определенныениe выводы до того, как

эта архитектура будет утверждена в рамках детального плана проекта, представляет значительную ценность с экономической точки зрения.

С появлением повторяемых, структурированных методов (таких, как, например, АТАМ. рассматриваемый в главе 11) оценка архитектуры превратилась в относи­тельно недорогой механизм смягчения рисков. В конце концов, убедиться в том, что архитектура соответствует поставленным задачам, требует здравый смысл. Итак, оценка архитектуры должна стать стандартным компонентом любой методики архитектурно-ориентированной разработки.

Когда?

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

С другой стороны, оценку архитектуры можно проводить многократно — на разных этапах жизненного цикла системы. Если архитектура находится в зача­точном состоянии, принятые решения следует оценивать наравне с теми, кото­рые еще только обсуждаются. Выбирайте из множества архитектурных альтернатив наиболее подходящие варианты. Если архитектура готова или близка к состоя­нию готовности, проверьте ее, не дожидаясь, пока проект перейдет в стадию дли­тельной и дорогостоящей разработки. Оценка будет весьма уместной, если вам придется иметь дело с существующей системой, представленной к модификации, переносу, интеграции с другими системами и любым прочим значимым меропри­ятиям по модернизации. Наконец, оценка архитектуры очень информативна: до­вольно часто при разработке новых проектов требуется разобраться в том, каким образом унаследованная система удовлетворяет (и удовлетворяет ли?) предъяв­ленные к ней требования по атрибутам качества. Более того, принимая решение о приобретении крупной программной системы с предположительно длительным сроком службы, компания-покупатель обязательно должна разобраться в ее ар­хитектуре. В результате ее оценки становится понятно, насколько система при­годна с точки зрения реализации ею важнейших атрибутов качества.

Наконец, оценка помогает выбрать один из двух вариантов архитектуры — тот, что в наибольшей степени соответствует критериям «добротности».