Проверка соответствия архитектуре

Когда архитектура составлена и задействована, наступает этап сопровождения. Для того чтобы обеспечить на этом этапе согласованность архитектуры и ее представления, нужно все время быть начеку. Область эта довольно молода, однако в последние годы в ней ведутся довольно интенсивные исследования. Современное состояние методик восстановления архитектуры исходя из существующей системы и проверки ее согласованности первоначальной архитектуре представлено в главе 10 ("Реконструкция программной архитектуры»).

1.3. Из чего складывается «качественная» архитектура?

Если утверждение о том, что, располагая одними и теми же техническими требованиями, два архитектора в двух компаниях создадут разные архитектуры, верно, 70 как эти архитектуры оценивать? Другими словами, какая из них правильная!

'Не существует такой архитектуры, которую можно было бы признать однозначно хорошей или однозначно плохой. Варианты архитектуры могут более или менее соответствовать поставленной задаче. Скажем, распределенная трехзвенная клиент-серверная архитектура идеально подходит для системы управления финансами в крупной компании, но в то же время совершенно не годится для авиационных приложений. Архитектуру, вполне отвечающую требованию по высокой модифицируемости, не имеет смысла использовать для создания одноразовой опытной системы. Один из главных постулатов этой книги заключается в том, что варианты архитектуры можно оценивать, и это один из факторов, обосновывающих повышенное к ним внимание, однако проводить такую оценку можно только в контексте конкретных задач.

Тем не менее в ходе проектирования архитектуры следует придерживаться ряда практических правил. Несоблюдение какого-то одного из них не означает, что архитектуру следует полностью забраковать; просто в причинах этого несоблюдения неплохо бы разобраться.

Все наши наблюдения делятся на две части: рекомендации по процессу и рекомендации по продукту (они же структурные рекомендации). Рекомендации по процессу таковы.

♦ Архитектура должна разрабатываться одним архитектором или небольшой командой архитекторов с очевидным руководителем.

♦ Архитектор (пли команда архитекторов) должен знать функциональные требования к системе и располагать четким, отсортированным согласно приоритетам перечнем атрибутов качества (примерами которых могут быть безопасность и модифицируемость), которым предполагаемая архитектура должна соответствовать.

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

♦ Содержание архитектуры необходимо раскрыть для всех заинтересованных в системе лиц; последние должны принимать активное участие в ее обсуждении.

+ Архитектуру следует проанализировать на предмет значимых количественных характеристик (например, максимальной производительности) и формально оценить па предмет атрибутов качества, причем сделать это нужно на том этапе, когда вносить поправки еще не поздно.

♦ Архитектура должна предусматривать возможность инкрементной (пошаговой) реализации; для этого следует создать «макет» (skeletal) системы и при минимальной функциональности испытать на нем все каналы связи. Макет системы можно использовать для инкрементного «наращивания» системы, тем самым уменьшив затраты на интеграцию и тестирование (см. главу 7, раздел 7.4).

♦ Все области состязаний за ресурсы в конечной архитектуре должны быть, во-первых, немногочисленными, а во-вторых, ясно определенными; порядок разрешения этих конфликтов необходимо четко обозначить, информации) о нем распространить и впоследствии поддерживать. В частности, если трудности возникают в связи с уровнем использования сети, архитектор должен составить (и провести в жизнь) нормативы, согласно которым все группы разработчиков должны будут соблюдать минимальный уровень сетевого трафика. Если же требуется обеспечить высокую производительность, архитектор должен определить (и провести в жизнь) временные ресурсы для основных потоков.

Что касается структурных правил, то их мы представляем следующим образом.

♦ Архитектура должна состоять из строго очерченных модулей, а функциональные обязанности между ними должны распределяться согласно принципам сокрытия информации и разделения задач. На основе информационной закрытости должны строиться (прежде всего) те модули, в которых инкапсулируется гиперчувствителыюсть вычислительной инфраструктуры, — при внесении изменений в инфраструктуру они уберегают от корректировки большую часть программного обеспечения.

♦ Каждый модуль должен иметь четкий интерфейс, инкапсулирующий или «скрывающий» изменяемые аспекты (в частности, стратегии реализации и варианты структур данных) от стороннего, обращающегося к его средствам программного обеспечения. Наличие подобных интерфейсов позволяет добиться определенной независимости в действиях различных групп разработчиков.

♦ Атрибуты качества должны реализовываться с привлечением хорошо изученных архитектурных тактик и на индивидуальной основе (см. главу 5 «Реализация качества»).

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

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

♦ В состав архитектуры систем с параллельной обработкой должны входить четко заданные процессы или задачи, которые могут соответствовать, а могут и не соответствовать структуре декомпозиции на модули. Иначе говоря, любой такой процесс может распространяться на несколько модулей; с другой стороны, процедуры в некоторых модулях могут вызываться как элементы нескольких процессов (этот принцип реализован в системе А-7Е — см. конкретный пример в главе 3).

♦ Все задачи и процессы следует писать так, чтобы обеспечить удобство их переназначения на другой процессор (даже в период прогона).

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

По мере того как вы будете знакомиться с представленными в этой книге кон­кретными примерами успешного решения той или иной архитектурной задачи, вспоминайте эти правила и проверяйте, насколько они соблюдались в каждом случае. Представленный набор правил не претендует ни на полноту, ни на безус­ловность; тем не менее он послужит ориентиром для любого архитектора, при­ступающего к решению архитектурно-проектной задачи.

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

На материале настоящей главы мы пытались доказать, что факторы влияния на архитектуру отнюдь не исчерпываются функциональными требованиями к си­стеме. Любая архитектура — это в равной степени результат применения навы­ков архитектора, технической базы, которой он располагает, и коммерческих за­дач компании, в которой он работает. В свою очередь архитектура, пополняя собой техническую базу и открывая новые возможности продвижения на рынки, ока­зывает обратное влияние на среду своего «обитания». Мы определили архитек­турно-экономический цикл и представили его как лейтмотив книги, однако не стоит забывать, что в следующих главах это понятие будет раскрываться.

Наконец, мы изложили ряд практических правил, соблюдение которых обыч­но обеспечивает создание удачных вариантов архитектуры.

Далее мы углубимся в рассмотрение программной архитектуры как таковой.

1.5. Дискуссионные вопросы

1. В какой степени особенности вашей компании влияют на характер разра­батываемых в ней вариантов архитектур? Существует ли обратное влия­ние?

2. Какие коммерческие задачи вашей компании обусловливают (или обуслов­ливали) создание вариантов программной архитектуры?

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