Роль архитектуры

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

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

Один из ответов кроется в том, насколько понятными окажутся взаимосвязи между «кирпичиками» в приложении. При удачном решении взаимосвязи просты и понятны, несмотря на их количество. При неудачном – связи запутанны настолько, что их почти невозможно воспринять (т.н. антипаттерн «Спагетти»). Очевидно, что простые взаимосвязи в системе позволяют создавать системы большего масштаба. В качестве примера можно привести управление армией. Преимущество имеет та армия, у которой более четкая структура и дисциплина. Армия без четкой иерархии и дисциплины превращается в плохо управляемую толпу. По аналогии сложная система без упорядочивания превращается в плохо контролируемый хаос.

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

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

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

Правила организации системы связывают с ее архитектурой. Существует множество определений данного понятия. Например, на ресурсе http://www.sei.cmu.edu/architecture/definitions.html приводится более сотни определений архитектуры. Приведем в качестве примера определение согласно стандарту IEEE 1471: «Архитектура – это фундаментальная организация системы, реализованная в ее компонентах, отношений этих компонент друг с другом и с внешней средой и принципах, определяющих структуру и развитие системы».

Из множества определений архитектуры можно выделить следующие наиболее часто встречающиеся положения[6]:

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

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

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

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

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

6. Архитектура может соответствовать одному из архитектурных стилей. Архитектурные стили очень похожи на паттерны или образцы, рассматривавшиеся ранее, но в отличие от последних имеют не локальный масштаб, а масштаб всего приложения. Образцами могут быть известные удачные проекты, например, WWW, Java, Eclipse и др. Некоторые архитектурные стили получили собственные имена: «Классная доска», «Клиент-сервер», «Сервис-ориентированная архитектура» и пр.

Форма описания архитектуры на данный момент не стандартизована. В большинстве случаев архитектурная документация оформляется по внутренним правилам той или иной организации. Тем не менее, попытки формализовать описание архитектур не прекращаются. Различными фирмами разработано несколько языков описания архитектур: AADL, Wright, Acme, xADL и др. На стандарт языка описания архитектур де-факто претендует UML.