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

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

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

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

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

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

Архитектура определяет

Когда речь заходит об "архитектуре", обычно не возникает недостатка в определениях. Есть даже web-сайты, которые собирают такие определения. Давайте использовать определение стандарта IEEE Std 1472000, и IEEE 1471 Рекомендуемые методы описания архитектуры преимущественно-программных систем IEEE.

Вот это определение, в котором жирным шрифтом выделены основные характеристики.

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

В этом стандарте также определяются следующие термины. связанные с данным определением:

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

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

Миссия - это применение или действие, для которого одно или несколько заинтересованных лиц планируют использовать систему в соответствии с некоторым набором условий.

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

Мы видим, что в определениях часто употребляется термин "компонент". Тем не менее, большая часть определений архитектуры не определяет термина "компонент", и IEEE 1471 - не исключение, поскольку намеренно оставляет это понятие неопределенным, чтобы оно соответствовало множеству толкований, возможных в отрасли. Компонент может быть логическим или физическим, технологически-независимым или технологически-связанным, крупно- или мелкогранулированным. Я использую определение компонента по спецификации UML 2.0 в достаточно широком смысле, что позволяет охватить различные элементы архитектуры, которые могут нам встретиться, в том числе объекты, технологические компоненты (такие как корпоративные компоненты JavaBean), сервисы, программные модули, традиционные системы, архивы приложений и т. д. Вот определение термина "компонент" по спецификации UML 2.0:

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

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

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

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

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

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

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

Архитектура определяет структуру

Если вы попросите описать "архитектуру", то девять человек из десяти обязательно упомянут о структуре. Это понятие в английском языке часто связывается со строительством зданий или некоторых других инженерных сооружений (engineering structure), например, мостов. Хотя существуют и другие характеристики этих элементов, такие как поведение, соответствие цели и даже эстетика, но именно термин "структура (structure)" наиболее известен и чаще всего упоминается.

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

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

Архитектура определяет поведение

Наряду с определением структурных элементов любая архитектура определяет взаимодействия между этими структурными элементами. Это такие взаимодействия, которые обеспечивают желаемое поведение системы. На рисунке представлена диаграмма сценария UML, которая показывает несколько взаимодействий, которые в сумме позволяют системе поддерживать создание заказа в системе обработки заказов. Мы видим здесь пять взаимодействий. Сначала, деятель Sales Clerk создает заказ при помощи экземпляра класса OrderEntry. Экземпляр класса OrderEntry получает сведения о клиенте при помощи экземпляра класса CustomerManagement. Затем экземпляр класса OrderEntry использует экземпляр класса AccountManagement для того, чтобы создать заказ, внести в него элементы заказа, а затем разместить заказ. 

Архитектура концентрируется на значимых элементах

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

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

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

Архитектура уравновешивает потребности заинтересованных лиц

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

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

• Конечный пользователь заинтересован в интуитивно понятном и корректном поведении, производительности, надежности, удобстве использования, доступности и безопасности;

• Системный администратор заинтересован в интуитивно понятном поведении, управлении и инструментах мониторинга;

• Специалист по маркетингу заинтересован в конкурентноспособных функциях, времени до выхода программы, позиционировании среди других продуктов и в стоимости;

• Клиент заинтересован в цене, стабильности и возможности планировать;

• Разработчик заинтересован в понятных требованиях и простом и непротиворечивом принципе проектирования;

• Руководитель проекта заинтересован в предсказуемости хода проектирования, планировании, продуктивном использовании ресурсов и бюджета;

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

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

Архитектура воплощает решения на основе логического обоснования

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

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

Архитектура может соответствовать некоторому архитектурному стилю

Большинство архитектур построены на основе систем, которые используют сходные наборы интересов. Сходство может быть определено как архитектурный стиль, который можно рассматривать как особый вид шаблона, хотя этот шаблон часто является сложным и составным (когда одновременно применяются несколько шаблонов). Как и шаблон, архитектурный стиль представляет собой кодификацию опыта, и для разработчиков архитектур было бы неплохо ждать случая, чтобы снова использовать этот опыт. Примеры архитектурных стилей включают распределенный стиль, стиль "каналы и фильтры", стиль с централизованной обработкой данных, стиль, построенный на правилах и так далее. Конкретная система может демонстрировать более одного архитектурного стиля. Вот как описывают архитектурный стиль Шоу и Гарлан (Show and Garlan):

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

Еще одно определение в терминах UML:

Шаблон - это общее решение общей проблемы в данном контексте.

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

На архитектуру оказывает влияние ее окружение

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

И наоборот, как это ярко описано у Басса, Клементса и Кацмана (Bass, Clements и Kazman), архитектура тоже оказывает влияние на свое окружение. Создание архитектуры изменяет окружение не только с технологической точки зрения - оно может, например, привносить в организацию многократно используемые активы - создание архитектуры может также изменить среду в терминах навыков, доступных в пределах организации.

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

Стандарт IEEE Std 12207-1995, IEEE Standard for Information Technology -- Software Life Cycle Processes (Стандарт IEEE по информационным технологиям -- Процессы жизненного цикла приложения) определяет систему иначе, чем ранее упомянутое определение стандарта IEE 1471 (которое концентрируется на преимущественно-программных системах), но при этом согласуется с определением системы в области системного проектирования:

Системой называется интегрированный комплекс, состоящий из одного или более процессов, аппаратных устройств, программ, средств и людей, предоставляющий возможность удовлетворить данную потребность или условие. (из IEEE 12207)

Техническое описание "A configuration of the Rational Unified Process® for Systems Engineering (RUP SE)" содержит похожее определение.

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

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

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

Архитектура оказывает влияние на структуру коллектива

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

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

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

Архитектура представлена в каждой системе

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

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

Архитектура имеет особую область применения

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

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

Элементы, показанные на рисунке:

• Архитектура программного обеспечения (Software), главная тема данной статьи, как было определено выше;

• Архитектура аппаратного обеспечения (Hardware), которое включает такие элементы, как ЦПУ, память, жесткие диски, периферийные устройства, например, принтер, а также элементы, используемые для их соединения;

• Архитектура организации (Organization), которая включает элементы, имеющие отношение к бизнес-процессам, структурам организации, ролям и ответственности, а также основные области специализации организации;

• Структура информации (Information), включающая структуры, которые упорядочивают информацию;

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

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

Как и следовало ожидать, существуют корреспондирующие формы разработчик архитектуры (например, разработчик архитектуры программного обеспечения, разработчик архитектуры аппаратного обеспечения и так далее) и разработка архитектуры (например, разработка архитектуры программного обеспечения, разработка архитектуры аппаратного обеспечения и так далее).

И сейчас, когда мы рассмотрели эти определения, многие вопросы остались без ответа. В чем заключается разница между архитектурой корпорации и архитектурой системы? Является ли корпорация системой? Архитектура информации и архитектура данных, которая встречается в некоторых преимущественно-информационных программах - это одно и то же? К сожалению, на эти вопросы нет согласованных ответов.

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