Концепция: Архитектура программного обеспечения

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

Взаимосвязи
Основное описание

Введение

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

In An Introduction to Software Architecture, David Garlan and Mary Shaw suggest that software architecture is a level of design concerned with issues: "Beyond the algorithms and data structures of the computation; designing and specifying the overall system structure emerges as a new kind of problem. Structural issues include gross organization and global control structure; protocols for communication, synchronization, and data access; assignment of functionality to design elements; physical distribution; composition of design elements; scaling and performance; and selection among design alternatives." [GAR93]

Но архитектура - это более чем просто структура; рабочая группа IEEE по архитектуре определяет её как "концепция системы на самом высоком уровне в её окружении" [IEP1471]. Также она включает в себя соответствие требованиям целостности системы, экономическим ограничениям, эстетическим требованиям, и общему стилю. Архитектура не ограничивается взглядом "внутрь", но также рассматривает систему в целом в среде её пользователей и в среде её разработки - то есть, учитывается и окружение.

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

Описание архитектуры

Чтобы говорить об архитектуре программного обеспечения и обсуждать её, сначала нужно задать представление архитектуры, то есть задать способ описания наиболее важных её аспектов. В OpenUP описание архитектуры приводится в документе Артефакт: Architecture Notebook.

Представления архитектуры

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

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

Архитектура в центре внимания

Не смотря на то, что архитектурные представления могут описывать весь дизайн системы, архитектура сосредотачивается на следующих конкретных аспектах:

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

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

  • Эволюция системы - переход к следующему циклу разработки.
  • Повторное использование архитектуры или её частей, в контексте линейки продуктов.
  • Оценка вспомогательных показателей качества, таких как производительность, доступность, переносимость и безопасность.
  • Распределение разработки по группам и субподрядчикам.
  • Решения об использовании покупных компонентов.
  • Включение в большую систему.

Архитектурные паттерны

Архитектурные паттерны - это готовые к использованию варианты решения повторяющихся архитектурных проблем. Архитектурный фреймворк или архитектурная инфраструктура (middleware) - это набор компонентов, на основе которых можно построить архитектуру некоторого типа. Многие из архитектурных проблем решаются в фреймворке или инфраструктуре, обычно по отношению к определенной области: команды и элементы управления, MIS, система управления и пр.

Примеры архитектурных паттернов

В [BUS96] предложена группировка архитектурных паттернов по характеристикам систем, для которых они наиболее подходят, при этом одна из категорий относится к наиболее общим структурным вопросам. В таблице приведены категории, представленные в [BUS96], и соответствующие паттерны.

Категория Паттерн
Структура Слои (Layers)
Каналы и фильтры (Pipes and Filters)
Blackboard
Распределенные системы Брокер
Интерактивные системы Model-View-Controller
Presentation-Abstraction-Control
Адаптируемые (Adaptable) системы Reflection
Microkernel

Полное описание этих паттернов приведено в [BUS96].

Архитектурный стиль

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