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

Материал из Википедии — свободной энциклопедии
Перейти к: навигация, поиск

Архитектура программного обеспечения (англ. software architecture) — это высокоуровневая структура программной системы, дисциплина создания таких структур и документация по этим структурам. Архитектура является множеством структур, необходимых для рассуждения о программной системе, и включает элементы системы, связи между ними и свойства этих элементов и связей.[1]

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

Общепринятого определения «архитектуры программного обеспечения» не существует. Так, сайт Software Engineering Institute приводит более 150 определений этого понятия[2][3].

При этом важно отличать термин Архитектура ПО от таких понятий, как Архитектура предприятия и Системная архитектура. Архитектура предприятия описывает структуры бизнеса и его внутренние процессы (поток информации, взаимодействие между отделами и т.д.). Системная архитектура описывает элементы и их взаимодействие между собой в рамках всей системы и включает как программные, так и аппаратные элементы. Системная архитектура описывает элементы с точки зрения их функциональности, но не с точки зрения их структуры. И таким образом архитектура предприятия и системная архитектура создают среду, в которой живёт само ПО[4].

Обзор[править | править вики-текст]

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

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

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

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

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

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

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

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

Языки описания архитектуры (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 основных типа[4]:

  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.

Атрибуты качества ПО[править | править вики-текст]

Атрибуты качества ПО — это свойства ПО, по которым заинтересованные в нём лица оценивают его качество[4].

Примеры атрибутов качества ПО:

  • Производительность (англ. performance)
  • Безопасность (англ. security)
  • Модифицируемость (англ. modifiability)
  • Надёжность (англ. reliability)
  • Удобство использования (англ. usability)
  • Доступность (англ. availability)
  • Конфигурируемость (англ. configurability)
  • Возможность повторного использования (англ. reusability)

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

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

Описание атрибутов качества через сценарии[править | править вики-текст]

Software Engineering Institute предлагает описывать атрибуты качества через сценарии[4].

Сценарий атрибута качества — это описание 6 характеристик атрибута:

  • Источник — сущность, которая порождает стимул
  • Стимул — условие, которое оказывает воздействие на систему
  • Артефакт(ы) — часть системы, на которую было оказано воздействие
  • Среда — внешние условия, под которыми возник стимул
  • Ответ — действия, которые система производит в ответ на стимул
  • Измерение ответа — измерения, по которым будет оцениваться ответ системы

Пример сценария атрибута качества для доступности системы:

Источник Стимул Артефакты Среда Ответ Измерение ответа
Внутренние/внешние: люди, физические устройства, ПО, физическая инфраструктура или среда Ошибка: отсутствие, сбой, некорректная синхронизация, некорректный ответ Процессоры, коммуникационные каналы, хранилища постоянных данных, процессы Нормальная работа системы, запуск, остановка, восстановление, ухудшенная работа системы, перегрузка Предотвратить превращение дефекта в сбой.

Обнаружить дефект:

  • Записать дефект в лог
  • Информировать о дефекте соответствующие сущности (людей или системы)

Восстановиться после дефекта:

  • Лишить источник события возможности создавать новые дефекты
  • Быть временно недоступной на период восстановления
  • Исправить или замаскировать дефект/сбой или предотвратить наносимый им вред
  • Работать в ухудшенном режиме на период восстановления
Время или временной интервал, во время которого система должны быть доступна.

Процент доступности (например, 99,999%)

Время на обнаружение дефекта / Время на исправление дефекта

Время или временной интервал, во время которого система может работать в ухудшенном режиме

Процент (например, 99%) или скорость обработки (например, до 100 в секунду) дефектов определенного класса таким образом, что они не перерастают в сбой.

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

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

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

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

  • Многоуровневый шаблон (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).

Отличие архитектурного и неархитектурного проектирования[править | править вики-текст]

Архитектура ПО, которую также можно представить себе в виде разработки стратегии — это деятельность, связанная с определением глобальных ограничений, накладываемых на проектирование системы, такие как выбор парадигмы программирования, архитектурных стилей, стандарты разработки ПО, основанные на использовании компонентов, принципы проектирования и ограничения, накладываемые государственным законодательством. Неархитектурное проектирование, то есть разработка тактики — это деятельность, связанная с определением локальных ограничений проекта, такие как шаблоны проектирования, архитектурные модели, идиомы программирования и рефакторинга. Согласно «гипотезе напряжения/окрестности» (Intension/Locality Hyphotysis), различие между архитектурным и неархитектурным проектированием определяется критерием окрестности (Locality Criteria), согласно которому утверждение, что проект ПО не является локальным (а является архитектурным) истинно тогда и только тогда, когда программа, которая удовлетворяет этому критерию может быть расширена в программу, которая не удовлетворяет ему. Например, стиль приложения клиент-сервер является архитектурным стилем (стратегическим проектом), потому что программа, которая построена на этом принципе, может быть расширена в программу, которая не является клиент-сервером, например, путем добавления peer-to-peer узлов.

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

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

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

  1. 1 2 Documenting Software Architectures: Views and Beyond, 2010, P.1.1. Overview
  2. Documenting Software Architectures: Views and Beyond, 2010, P.1.2. Architecture and Quality Attributes
  3. Software Architecture:Glossary, Software Engineering Institute
  4. 1 2 3 4 Len Bass, Paul Clements, Rick Kazman. Software Architecture in Practice (3rd Edition) (SEI Series in Software Engineering). — 3 edition (October 5, 2012). — 2012. — 640 с. — ISBN 978-0321815736.

Литература[править | править вики-текст]

  • Paul Clements; Felix Bachmann; Len Bass; David Garlan; James Ivers; Reed Little; Paulo Merson; Robert Nord; Judith Stafford. Documenting Software Architectures: Views and Beyond. — Second Edition. — Addison-Wesley Professional, 2010. — ISBN 978-0-13-248861-7.
  • Len Bass, Paul Clements, Rick Kazman: Software Architecture in Practice, Third Edition. Addison Wesley, 2012, ISBN 978-0321815736 (This book, now in third edition, eloquently covers the fundamental concepts of the discipline. The theme is centered around achieving quality attributes of a system.)

Ссылки[править | править вики-текст]