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

Архитектура программного обеспе́чения (англ. software architecture) — совокупность важнейших решений об организации программной системы. Архитектура включает:

• выбор структурных элементов и их интерфейсов, с помощью которых составлена система, а также их поведения в рамках сотрудничества структурных элементов;
• соединение выбранных элементов структуры и поведения во всё более крупные системы;
• архитектурный стиль, который направляет всю организацию — все элементы, их интерфейсы, их сотрудничество и их соединение^[1][2].

Документирование архитектуры программного обеспе́чения (ПО) упрощает коммуникацию разработчиков, позволяет зафиксировать принятые проектные решения и предоставить информацию о них эксплуатационному персоналу системы^[3], повторно использовать компоненты и шаблоны проекта в других.

Общепринятого определения «архитектуры программного обеспечения» не существует. Так, сайт Института программной инженерии приводит более 150 определений этого понятия^[4][5].

Обзор[править | править код]

Область компьютерных наук с момента своего образования столкнулась с проблемами, связанными со сложностью программных систем. Ранее проблемы сложности решались разработчиками путём правильного выбора структур данных, разработки алгоритмов и применения концепции разграничения полномочий. Хотя термин «архитектура программного обеспечения» является относительно новым для индустрии разработки ПО, фундаментальные принципы этой области неупорядоченно применялись пионерами разработки ПО начиная с середины 1980-х. Первые попытки осознать и объяснить программную архитектуру системы были полны неточностей и страдали от недостатка организованности, часто это была просто диаграмма из блоков, соединенных линиями. В 1990-е годы наблюдается попытка определить и систематизировать основные аспекты данной дисциплины. Первоначальный набор шаблонов проектирования, стилей проектирования, передового опыта (best practices), языков описания и формальная логика были разработаны в течение этого времени^[6].

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

Являясь в настоящий момент своего развития дисциплиной без четких правил о «правильном» пути создания системы, проектирование архитектуры ПО всё ещё является смесью науки и искусства. Аспект «искусства» заключается в том, что любая коммерческая система подразумевает наличие применения или миссии. С точки зрения её пользователя, программная архитектура дает направление для движения и решения задач, связанных со специальностью каждого такого пользователя, например заинтересованного лица, разработчика ПО, группы поддержки ПО, специалиста по сопровождению ПО, специалиста по развертыванию ПО, тестера, а также конечных пользователей. В этом смысле архитектура программного обеспечения на самом деле объединяет различные точки зрения на систему. Тот факт, что эти несколько различных точек зрения могут быть объединены в архитектуре программного обеспечения, является аргументом в защиту необходимости и целесообразности создания архитектуры ПО ещё до этапа разработки ПО^[7][8][9].

История[править | править код]

Начало архитектуре программного обеспечения как концепции было положено в научно-исследовательской работе Эдсгера Дейкстры в 1968 году и Дэвида Парнаса Дэвида Парнаса^[en] в начале 1970-х. Эти ученые подчеркнули, что структура системы ПО имеет важное значение и что построение правильной структуры — критически важно. Популярность изучения этой области возросла с начала 1990-х годов вместе с научно-исследовательской работой по исследованию архитектурных стилей (шаблонов), языков описания архитектуры, документирования архитектуры и формальных методов.

В развитии архитектуры ПО как дисциплины играют важную роль научно-исследовательские учреждения. Мэри Шоу и Дэвид Гэрлан из университета Карнеги — Меллона написали книгу под названием «Архитектура программного обеспечения: перспективы новой дисциплины в 1996 году», в которой выдвинули концепции архитектуры ПО, такие как компоненты, соединители (connectors), стили и так далее. В Калифорнийском университете Ирвайна институт по исследованию ПО в первую очередь исследует архитектурные стили, языки описания архитектуры и динамические архитектуры.

Первым стандартом программной архитектуры является стандарт IEEE 1471: ANSI / IEEE 1471—2000: Рекомендации по описанию преимущественно программных систем. Он был принят в 2007 году, под названием ISO ISO / IEC 42010:2007.

Языки описания архитектуры[править | править код]

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

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

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

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

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

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

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

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

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

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

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

• 4+1
• RM-ODP (эталонная модель открытой распределенной обработки)
• Service-Oriented Modeling Framework (SOMF)

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

См. также[править | править код]

• Архитектура системы
• Архитектура компьютера
• Антипаттерн
• ArchiMate
• Модель C4

Примечания[править | править код]

Литература[править | править код]

• Mary Shaw. Software Architecture: Perspectives on an Emerging Discipline. — Prentice Hall, 1996..
• Paul Clements; Felix Bachmann; Len Bass; David Garlan; James Ivers; Reed Little; Paulo Merson; Robert Nord; Judith Stafford. Documenting Software Architectures: Views and Beyond. — 2-е изд. — Addison-Wesley Professional, 2010. — ISBN 978-0-13-248861-7.
• Len Bass, Paul Clements, Rick Kazman. Software Architecture in Practice. — 3-е изд. — Addison Wesley, 2012. — ISBN 978-0321815736. (Эта книга, теперь в третьем издании, покрывает фундаментальные концепции дисциплины, сосредотачиваясь на достижении качественных атрибутов системы.)

Ссылки[править | править код]

• Ретроспектива программных архитектур
• Software Architecture: Glossary, Software Engineering Institute (англ.)
• Architecture: Publications, Software Engineering Institute (англ.)

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