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

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

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

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

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

На самом высоком уровне проект архитектуры должен предоставлять структуру системы, но скрывать детали реализации; охватывать все случаи применения и сценарии; пытаться учитывать требования всех заинтересованных лиц; и удовлетворять настолько, насколько возможно, всем функциональные требованиям и требованиям к качеству.

В чем важность архитектуры программного обеспечения?

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

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

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

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

Чем занимаются разработчики архитектуры программного обеспечения?

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

Разработчик архитектуры программного обеспечения должен учитывать потребности клиента. Однако общий термин «клиент» обычно состоит из трех противоречащих областей ответственности: бизнес-требования, требования пользователя и системные требования. Бизнес-требования обычно определяют диапазон таких факторов, как бизнес-процессы, факторы производительности (такие как безопасность, надежность и пропускная способность), а также бюджетные ограничения и ограничения на издержки. Требования пользователя включают в себя дизайн интерфейса, производственные возможности и простоту использования программного обеспечения. Системные требования подразумевают возможности и ограничения оборудования, сети и среды выполнения. На рис. 1 показано, как могут различаться эти различные требования, поэтому разработчику необходимо создать архитектуру, подходящую для перекрывающихся областей.

Рис. 1. — конфликтные требования типичного клиента

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

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

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

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

Рис. 2. — поэтапный процесс архитектурного проектирования

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

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

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

Какие навыки требуются разработчику архитектуры программного обеспечения?

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

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

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

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

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

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

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

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

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

Симулятор должен:

• Моделировать определенные условия полета и создавать некоторые события, к которым относятся следующие:

  • Скоростной и высотный режим полета, запас горючего, их изменения со временем.

  • Модель самолета и ее характеристики по управляемости, возможным режимам полета и скорости реакции на различные команды.

  • Погода за бортом и ее изменения со временем.

  • Рельеф и другие особенности местности в текущий момент, их изменения со временем.

  • Исходный и конечный пункты полета, расстояние и основные характеристики рельефа между ними.

  • Исправность или неисправность элементов системы контроля полета и управления самолетом, показатели системы мониторинга и их изменение со временем.

  • Наличие пролетающих вблизи курса самолета других самолетов, их геометрические и скоростные характеристики.

  • Чрезвычайные ситуации, например, террористы на борту, нарушение герметичности корпуса, внезапные заболевания и "смерть" отдельных членов экипажа.

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

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

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

• выбор структурных элементов и их интерфейсов, с помощью которых составлена система, а также их поведения в рамках сотрудничества структурных элементов;

• соединение выбранных элементов структуры и поведения во всё более крупные системы;

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

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

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

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

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

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

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

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

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