Что такое программная архитектура?

Может быть, это еще один термин, который с большей натяжкой про% должает метафору строительства зданий (см. раздел «Действитель% но ли бы собираем программы?» на стр. 240)? Возможно, но это дейст% вительно полезная концепция. Программную архитектуру иногда еще называют проектированием верхнего уровня. Термин архитектура

лучше ассоциируется с идеями, заложенными в этой процедуре.

План программы

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

С такой высоты все подробности реализации не видны; мы наблюдаем только важнейшие элементы внутренней структуры программы и ос% новные характеристики ее поведения. Архитектурное представление решает следующие задачи:

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

•Определяет, какие компоненты должны быть связаны между собой.

•Способствует выявлению и определению характера всех основных интерфейсов системы, проясняя роли и ответственности различ% ных подсистем.

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

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

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

Будучи ранней стадией деятельности, разработка архитектуры впервые открывает перед нами возможность установить соответствие между

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

Конкретные проблемы, решаемые архитектурой, могут разниться в за% висимости от проекта. На этом этапе не важно, какой будет целевая платформа; архитектуру можно реализовать на разных машинах с по% мощью разных языков и технологий. Тем не менее:

•В некоторых проектах бывает необходимо указать конкретные ап% паратные компоненты, особенно в случае встроенного программно% го обеспечения.

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

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

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

Точки зрения

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

Концептуальное представление

Иногда его еще называют логическим. Оно показывает основные части системы и их взаимосвязи.

Представление реализации

Это представление с точки зрения конкретно реализуемых моду% лей, которое может отличаться от чисто концептуальной модели.

Представление процесса

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

Представление развертывания

Это представление применяется для размещения задач в физических узлах распределенной системы. Например, можно распределить

Цена вопроса

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

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

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

функциональность между сервером базы данных и пулом шлюзов веб%интерфейсов.

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

Где и когда этим заниматься?

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

Чья это работа?

Как мы видели, архитектура программного обеспечения затраги% вает всех участников проекта, а не только программистов. С дру% гой стороны, выработка архитектуры осуществляется значи% тельно меньшей по числу группой людей. На нее падает большая ответственность.

Разработчик архитектуры называется программным архитек# тором. Это внушительный титул, отчасти спорный, как и «ин% женер». «Настоящие» архитекторы должны пройти обучение, сертификацию и достичь определенного профессионального мас% терства, чтобы только называться архитекторами. В мире про% граммирования такие требования не предъявляются.

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

Однако в мелких проектах, в меньшей мере требующих специ% ального опыта в области архитектуры, ее разрабатывают сами программисты. Обходятся без артиллерии главного калибра. Будьте готовы принять участие в архитектурных разработках.

Храните описание системной архитектуры в таком месте, где оно доступно всем, кому может потребоваться: программистам, ответственным за со& провождение и установку, менеджерам, а возможно, и клиентам.

Архитектура является начальным проектом системы. Поэтому она яв% ляет собой первый шаг в разработке после утверждения технических требований. Необходимо заранее выработать спецификации, потому что выработка архитектуры оказывается первой возможностью рас% смотреть и проверить проектные решения, которые окажут самое су% щественное влияние на проект. Здесь могут выявиться слабые места и потенциальные проблемы. Если отвергнуть неудачное решение еще на этом этапе, можно сэкономить много времени, сил и денег. Менять ос% нование системы, когда на нем будет построен большой объем кода, значительно дороже.

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