Архитектура по

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

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

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

Для представления архитектуры (точнее различных входящих в нее структур) удобно использовать графические языки. На настоящий момент наиболее проработанным и наиболее широко используемым из них является унифицированный язык моделирования (Unified Modeling Language, UML), хотя на высоком уровне абстракции архитектуру системы обычно описывают просто набором именованных прямоугольников, соединенных линиями и стрелками, представляющими возможные связи.

UML предлагает использовать для описания архитектуры 8 видов диаграмм.

• Диаграммы классов

• Диаграммы объектов

• Диаграммы компонентов

• Диаграммы развертывания

• Диаграммы деятельностей

• Диаграммы сценариев

• Диаграммы взаимодействия

• Диаграммы состояний

Диаграммы классов

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

Диаграммы объектов

Показывают объекты системы и их связи, в некотором конкретном состоянии или суммарно. Используются редко.

Диаграммы компонентов

Это компоненты в узком смысле, компоненты «физического» представления системы — файлы с исходным кодом, динамически подгражаемые библиотеки, HTML-странички и пр. Они определяют разбиение системы на набор сущностей, расматриваемых как атомарные с точки зрения ее сборки и конфигурационного управления. Используются редко.

Диаграммы развертывания

Показывают привязку (в некоторый момент времени или постоянную) компонентов системы (во узком смысле) к физическим устройствам — машинам, процессорам, принтерам, маршрутизаторам и пр. Используются редко.

Диаграммы деятельностей

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

Диаграммы сценариев

Показывают возможные сценарии обмена сообщениями/вызовами во времени между различными компонентами системы (в широком смысле). Эти диаграммы являются подмножеством другого графического языка — языка диграмм последовательностей сообщений (Message Sequence Charts, MSC). Используются почти так же часто, как диаграммы классов.

Диаграммы взаимодействия

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

Диаграммы состояний

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

Образцы проектирования и архитектурные стили

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

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