Как пасти котов. Наставление для программистов, руководящих другими программистами

Поскольку в формализованном виде дисциплина архитектурного планирования появилась относительно недавно, в ее рамках существует несколько конкурирующих концепций. Мальво (Malveau) и Маубрей (Mowbray)[62] – два эксперта в этой области – приводят список основных концепций. Это каркас Закмана (Zachman), открытая распределенная обработка (Open Distributed Processing, ODP), анализ предметной области, модель 4+1 представлений программной архитектуры и, наконец, академическая программная архитектура. Это уже немало. А знакомы ли вы с положениями каждой из них? Если нет, торопитесь – принимайтесь за изучение перечисленных концепций, поскольку они предоставляют любому специалисту прекрасный инструментарий для создания многократно используемых систем.

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

• Сможет ли система предоставить пользователю комфортные условия работы и функционировать согласно его ожиданиям?

• Может ли система функционировать в соответствии с проектным решением, предусматривает ли она модификацию и сопровождение по мере изменения коммерческих потребностей и технологии?

• Минимизирована ли сложность высокоуровневых архитектурных характеристик системы?

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

• В связи с тем, что ожидается реализация решений в аппаратной части, особое внимание следует уделить созданию, конфигурированию и сопровождению инфраструктуры.

• Достаточна ли компетентность персонала для сопровождения систем, построенных на основе новых технологий? Если в конструировании[63] применяются старые технологии, насколько они перспективны с точки зрения продолжительности использования системы?

Ни в коем случае не забывайте об этих вопросах и проблемах. Обязательно сформулируйте их и донесите до группы разработчиков – ведь умение четко сформулировать вопросы иногда важнее, чем даже знание правильных ответов на них. Может быть, конечно, в этом я преувеличиваю, но, полагаю, мысль вам понятна. Способов наделать глупостей всегда более чем достаточно, и первый вопрос, который вы должны себе задать, звучит так: «Что я должен делать? Какое решение будет правильным?» Задавая адекватные вопросы, вы сможете организовать создание стройной, мощной и долговечной архитектуры.

Аналитические позиции как средство управления проектными ограничениями

Чтобы решить проблемы, возникающие благодаря проектным ограничениям, необходимо иметь представление о позициях, с которых анализируются любые корпоративные варианты архитектуры. Аналитическая позиция – это, по сути, точка зрения на проектное решение, исходя из которой оно анализируется. Эта позиция, или точка зрения, изменяется по мере изучения системы с разных сторон, исходя из степени серьезности различных проектных ограничений. Вне зависимости от конкретной концепции создания архитектуры все исследователи выделяют несколько общих аналитических позиций, формулируя их в виде вопросов.

• Как будет проходить взаимодействие пользователей с системой? (Эту аналитическую позицию часто называют вариантной.)

• Какие компоненты требуется собрать для того, чтобы обеспечить функционирование системы?

• Каков механизм взаимодействия компонентов, благодаря которому система функционирует?

• Какие технологии в наибольшей степени приспособлены для создания данного программного обеспечения?

• Как предполагается поставить систему клиенту?

Задаетесь ли вы этими вопросами о предполагаемом продукте в ходе проектных совещаний (о них мы говорили в предыдущей главе)? Без них не обойтись – в противном случае у вас получится случайная архитектура, а это крайне опасный негативный эталон. Не забывайте, что переработать архитектуру значительно сложнее и потенциально разрушительнее, чем реконструировать компоненты. Этот фактор риска в процессе проектирования следует постоянно иметь в виду.

Переработать архитектуру значительно сложнее и потенциально разрушительнее, чем реконструировать компоненты.