Языки описания архитектуры

Языки описания архитектуры (ADLS) используются для описания архитектуры программного обеспечения. Различными организациями было разработано несколько различных ADLS, в том числе AADL (стандарт SAE), Wright (разработан в университете Carnegie Mellon), Acme (разработан в университете Carnegie Mellon), xADL (разработан в UCI), Darwin (разработан в Imperial College в Лондоне), DAOP-ADL (разработан в Университете Малаги), а также ByADL (Университет L’Aquila, Италия). Общими элементами для всех этих языков являются понятия компонента, коннектора и конфигурации. Также, помимо специализированных языков, для описания архитектуры часто используется унифицированный язык моделирования UML.

Виды (views)[править | править вики-текст]

Архитектура ПО обычно содержит несколько видов, которые аналогичны различным типам чертежей в строительстве зданий. В онтологии, установленной ANSI / IEEE 1471—2000, виды являются экземплярами точки зрения, где точка зрения существует для описания архитектуры с точки зрения заданного множества заинтересованных лиц.

Архитектурный вид состоит из 2 компонентов:

• Элементы

• Отношения между элементами

Архитектурные виды можно поделить на 3 основных типа^[6]:

1. Модульные виды (англ. module views) — показывают систему как структуру из различных программных блоков.

2. Компоненты-и-коннекторы (англ. component-and-connector views) — показывают систему как структуру из параллельно запущенных элементов (компонентов) и способов их взаимодействия (коннекторов).

3. Размещение (англ. allocation views) — показывает размещение элементов системы во внешних средах.

Примеры модульных видов:

• Декомпозиция (англ. decomposition view) — состоит из модулей в контексте отношения «является подмодулем»

• Использование (англ. uses view) — состоит из модулей в контексте отношения «использует» (т.е. один модуль использует сервисы другого модуля)

• Вид уровней (англ. layered view) — показывает структуру, в которой связанные по функциональности модули объединены в группы (уровни)

• Вид классов/обобщений (англ. class/generalization view) — состоит из классов, связанные через отношения «наследуется от» и «является экземпляром»

Примеры видов компонентов-и-коннекторов:

• Процессный вид (англ. process view) — состоит из процессов, соединённых операциями коммуникации, синхронизации и/или исключения

• Параллельный вид (англ. concurrency view) — состоит из компонентов и коннекторов, где коннекторы представляют собой «логические потоки»

• Вид обмена данными (англ. shared-data (repository) view) — состоит из компонентов и коннекторов, которые создают, сохраняют и получают постоянные данные

• Вид клиент-сервер (англ. client-server view) — состоит из взаимодействующих клиентов и серверов и коннектором между ними (например, протоколов и общих сообщений)

Примеры видов размещения:

• Развертывание (англ. deployment view) — состоит из программных элементов, их размещения на физических носителях и коммуникационных элементов

• Внедрение (англ. implementation view) — состоит из программных элементов и их соответствия файловым структурам в различных средах (разработческой, интеграционной и т.д.)

• Распределение работы (англ. work assignment view) — состоит из модулей и описания того, кто ответственен за внедрение каждого из них

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

Архитектурные шаблоны[править | править вики-текст]

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

Примеры архитектурных шаблонов:

• Многоуровневый шаблон (Layered pattern). Система разбивается на уровни, которые на диаграмме изображаются один над другим. Каждый уровень может вызывать только уровень на 1 ниже него. Таким образом разработку каждого уровня можно вести относительно независимо, что повышает модифицируемость системы. Недостатками данного подхода являются усложнение системы и снижение производительности.

• Шаблон посредника (Broker pattern). Когда в системе присутствует большое количество модулей, их прямое взаимодействие друг с другом становится слишком сложным. Для решения проблемы вводится посредник (например, шина данных), по которой модули общаются друг с другом. Таким образом, повышается функциональная совместимость модулей системы. Все недостатки вытекают из наличия посредника: он понижает производительность, его недоступность может сделать недоступной всю систему, он может стать объектом атак и узким местом системы.

• Шаблон «Модель-Представление-Контроллер» (Model-View-Controller pattern). Т.к. требования к интерфейсу меняются чаще всего, то возникает потребность часто его модифицировать, при этом сохраняя корректное взаимодействие с данными (чтение, сохранение). Для этого в шаблоне Model-View-Controller (MVC) интерфейс отделён от данных. Это позволяет менять интерфейсы, равно как и создавать их разные варианты. В MVC система разделена на:

  • Модель, хранящую данные

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

  • Контроллер, являющийся посредником между видами и моделью

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

• Клиент-серверный шаблон (Client-Server pattern). Если есть ограниченное число ресурсов, к которым требуется ограниченный правами доступ большого числа потребителей, то удобно реализовать клиент-серверную архитектуру. Такой подход повышает масштабируемость и доступность системы. Но при этом сервер может стать узким местом системы, при его недоступности становится недоступна вся система.

Базовые фреймворки для архитектуры ПО[править | править вики-текст]

Существуют следующие фреймворки (англ. software architecture frameworks), относящихся к области архитектуры ПО:

• 4+1

• RM-ODP (Reference Model of Open Distributed Processing)

• Service-Oriented Modeling Framework (SOMF)

Такие примеры архитектур как фреймворк Захмана (Zachman Framework), DODAF и TOGAF относятся к области архитектуры предприятия (enterprise architectures).

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

Как ни парадоксально, несмотря на постепенное вызревание соответствующей дисциплины, мы пока не можем дать краткий и ясный ответ на простой вопрос: что такое программная архитектура? Общепринятых дефиниций не существует. На сайте Института программной инженерии (Software Engineering Institute, SEI), посвященном практическим аспектам архитектуры, Пол Клементс приводит несколько определений. И хотя отсутствие согласия относительно такого определения не стало существенным препятствием к развитию самой дисциплины, его достижение оказалось весьма трудной задачей при создании стандарта IEEE [1].

Область программной архитектуры делится на несколько подобластей. Рабочая группа IFIP 2.10 (International Federation of Information Processing — Международная федерация по обработке информации) определяет следующие пять.

Архитектурный проект: как мы создаем архитектуру?

Анализ: как мы на основе архитектуры отвечаем на вопросы о свойствах конечного продукта?

Реализация: как мы создаем систему на базе архитектурного описания?

Представление: как мы создаем надежные артефакты, чтобы «донести» архитектуру до людей и машин?

Экономика: какие архитектурные проблемы влияют на бизнес-решения?

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

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