Портал о современной архитектуре и дизайне

В архитектуре нет недостатка в определениях. Даже некоторые веб-сайты поддерживают коллекции определений (SEI 2009). Определение, используемое в этой книге, - это то, что взято из IEEE 1471-2000, IEEE Рекомендуемая практика для архитектурного описания программно-интенсивных систем (IEEE 1471 2000). Это определение следует, поскольку основные характеристики выделены:

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

Как вы можете видеть, термин компонент используется в этом определении. Однако большинство определений архитектуры не определяют термин « компонент» , и IEEE 1471 не является исключением, выбирая его намеренно неопределенным, поскольку этот термин предназначен для покрытия многих интерпретаций в отрасли. Компонент может быть логичным или физическим, технологически независимым или технологичным, крупнозернистым или мелкозернистым. Для целей этой книги мы используем определение компонента из спецификации унифицированного языка моделирования (UML):

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

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

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

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

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

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

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

На рисунке 2.2 показан пример некоторых структурных элементов. На этом рисунке показана диаграмма компонентов UML, содержащая некоторые структурные элементы в системе обработки заказов. Вы видите три компонента: «Ввод заказов», «Управление клиентами» и «Управление учетными записями». Компонент ввода заказа отображается в зависимости от компонента управления клиентами, а также от компонента управления учетными записями, обозначенного зависимостью UML.

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

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

Рисунок 2.3 представляет собой диаграмму последовательности UML, показывающую несколько взаимодействий, которые вместе позволяют системе поддерживать создание порядка в системе обработки заказов. На рисунке показано пять взаимодействий. Во-первых, оператор Sales Clerk создает заказ, используя экземпляр компонента Entry Order.Экземпляр Order Entry получает детали клиента, используя экземпляр компонента Customer Management. Затем экземпляр Order Entry использует экземпляр компонента Account Management для создания заказа, заполнения заказа с элементами заказа и размещения заказа.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Архитектура подвержена влиянию ее окружающей среды

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

И наоборот, как красноречиво описано в Software Architecture in Practice , 2nd ed. (Bass 2003), архитектура может также влиять на ее среду. Например, создание архитектуры может предоставлять повторно используемые активы владелической организации, тем самым делая такие активы доступными для следующих усилий в области развития.Другим примером является выбор программного пакета, который используется в архитектуре, такой как система управления взаимоотношениями с клиентами (CRM), которая впоследствии требует от пользователей изменения процессов, которые они выполняют, чтобы они соответствовали способу работы пакета.

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

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

Каждой из этих групп могут потребоваться разные наборы навыков. Поэтому имеет смысл согласовать структуры команды разработки программного обеспечения с архитектурой после ее определения. Часто, однако, на архитектуру влияет исходная структура команды, а не наоборот. Лучше избегать этой ловушки, потому что результат обычно представляет собой архитектуру, которая меньше, чем идеальна. Закон Конуэй гласит: «Если у вас есть четыре группы, работающие над компилятором, вы получите четырехпроходный компилятор». На практике архитекторы часто непреднамеренно создают архитектуры, которые отражают организацию, создающую архитектуру.

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

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

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

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

Архитектура имеет особый масштаб

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

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

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

Конфигурация Rational Unified Process для системной инженерии (RUP SE), также известная как разработка моделей с управляемым двигателем (MDSD), содержит аналогичное определение:

Различные элементы, показанные на рисунке 2.4 ,

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

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

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

 

Cовременная архитектура и дизайн