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

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

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

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

1. Все является компромиссом
2. «Почему важнее, чем как»

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

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

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

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

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

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

Область применения

Мнения относительно сферы применения архитектур программного обеспечения различаются:

• Макроскопическая структура системы : это относится к архитектуре как абстракции более высокого уровня программной системы, которая состоит из набора вычислительных компонентов вместе с соединителями , которые описывают взаимодействие между этими компонентами.
• Важные вещи — какими бы они ни были : это относится к тому факту, что архитекторы программного обеспечения должны интересоваться теми решениями, которые оказывают большое влияние на систему и ее заинтересованные стороны.
• То, что имеет фундаментальное значение для понимания системы в ее среде
• Вещи, которые люди считают трудными для изменения : поскольку проектирование архитектуры происходит в начале жизненного цикла программной системы, архитектор должен сосредоточиться на решениях, которые «должны» быть правильными с первого раза. Следуя этому подходу, проблемы архитектурного проектирования могут стать неархитектурными, как только будет преодолена их необратимость.
• Набор решений по архитектурному проектированию : архитектуру программного обеспечения не следует рассматривать просто как набор моделей или структур, но она должна включать решения, которые приводят к созданию этих конкретных структур, и их обоснование. Это понимание привело к масштабным исследованиям в области управления знаниями об архитектуре программного обеспечения .

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

Характеристики

Архитектура программного обеспечения демонстрирует следующее:

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

Разделение задач : общепринятым способом снижения сложности для архитекторов является разделение задач, лежащих в основе проектирования. Документация по архитектуре показывает, что все проблемы заинтересованных сторон решаются путем моделирования и описания архитектуры с отдельных точек зрения, связанных с различными проблемами заинтересованных сторон. Эти отдельные описания называются архитектурными видами (см., например, модель архитектурного представления 4+1 ).

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

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

Концептуальная целостность: термин, введенный Фредом Бруксом в его книге 1975 года «Мифический человеко-месяц» для обозначения идеи о том, что архитектура программной системы представляет собой общее видение того, что она должна делать и как она должна это делать. Это видение должно быть отделено от его реализации. Архитектор берет на себя роль «хранителя видения», следя за тем, чтобы дополнения к системе соответствовали архитектуре, сохраняя тем самым концептуальную целостность .

Когнитивные ограничения: наблюдение, впервые сделанное в 1967 году программистом Мелвином Конвеем, о том, что организации, разрабатывающие системы, вынуждены создавать проекты, которые являются копиями коммуникационных структур этих организаций. Фред Брукс представил его более широкой аудитории, когда процитировал статью и идею в «Мифическом человеко-месяце» , назвав ее законом Конвея .

Мотивация

Архитектура программного обеспечения — это «интеллектуально постижимая» абстракция сложной системы. Эта абстракция дает ряд преимуществ:

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

История

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

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

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

IEEE 1471-2000 , «Рекомендуемая практика описания архитектуры систем с интенсивным программным обеспечением», был первым формальным стандартом в области архитектуры программного обеспечения. Он был принят ISO в 2007 году как ISO/IEC 42010:2007 . В ноябре 2011 года стандарт IEEE 1471–2000 был заменен стандартом ISO/IEC/IEEE 42010:2011 «Системная и программная инженерия. Описание архитектуры» (опубликованным совместно IEEE и ISO).

В то время как в IEEE 1471 архитектура программного обеспечения относилась к архитектуре «программно-интенсивных систем», определенных как «любая система, в которой программное обеспечение оказывает существенное влияние на проектирование, создание, развертывание и развитие системы в целом», издание 2011 года. идет еще дальше, включая ISO/IEC 15288 и ISO/IEC 12207 определения системы в стандартах , которые охватывают не только аппаратное и программное обеспечение, но также «людей, процессы, процедуры, средства, материалы и природные объекты». Это отражает взаимосвязь между архитектурой программного обеспечения, архитектурой предприятия и архитектурой решения .

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

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

Архитектор программного обеспечения несет ответственность за согласование архитектурных характеристик (также известных как нефункциональные требования ) с бизнес-требованиями. Например:

• Для высокого уровня удовлетворенности клиентов необходимы доступность, отказоустойчивость, безопасность, возможность тестирования, восстановления, гибкость и производительность системы.
• Проведение слияний и поглощений (M&A) требует расширяемости, масштабируемости, адаптивности и функциональной совместимости.
• Ограниченный бюджет и время требуют осуществимости и простоты.
• Ускоренный вывод продукта на рынок требует ремонтопригодности, тестируемости и непригодности.

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

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

• что система будет делать в рабочем состоянии (функциональные требования)
• насколько хорошо система будет выполнять нефункциональные требования времени выполнения, такие как надежность, работоспособность, эффективность производительности, безопасность, совместимость, определенные в ISO/IEC 25010 :2011. стандарте
• время разработки нефункциональных требований, таких как ремонтопригодность и переносимость, определенных в стандарте ISO 25010:2011.
• бизнес-требования и экологический контекст системы, который может меняться со временем, например юридические, социальные, финансовые, конкурентные и технологические проблемы.

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

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

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

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

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

архитектуры

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

• Управление знаниями и коммуникация — это процесс изучения и управления знаниями, который необходим для проектирования архитектуры программного обеспечения. Архитектор программного обеспечения не работает изолированно. Они получают входные данные, функциональные и нефункциональные требования, а также контексты проектирования от различных заинтересованных сторон; и предоставлять результаты заинтересованным сторонам. Знания об архитектуре программного обеспечения часто неявны и сохраняются в головах заинтересованных сторон. Деятельность по управлению знаниями об архитектуре программного обеспечения заключается в поиске, передаче и сохранении знаний. Поскольку вопросы проектирования архитектуры программного обеспечения сложны и взаимозависимы, пробел в знаниях при проектировании может привести к неправильному проектированию архитектуры программного обеспечения. Примеры управления знаниями и коммуникационной деятельности включают поиск шаблонов проектирования, создание прототипов, обращение к опытным разработчикам и архитекторам, оценку проектов аналогичных систем, обмен знаниями с другими дизайнерами и заинтересованными сторонами, а также документирование опыта на вики-странице.
• Обоснование дизайна и принятие решений — это деятельность по оценке проектных решений. Эта деятельность имеет основополагающее значение для всех трех основных видов деятельности по архитектуре программного обеспечения. Это влечет за собой сбор и связывание контекстов принятия решений, формулирование проблем проектных решений, поиск вариантов решения и оценку компромиссов перед принятием решений. решений Этот процесс происходит на разных уровнях детализации при оценке существенных архитектурных требований и решений по архитектуре программного обеспечения, а также при анализе, синтезе и оценке архитектуры программного обеспечения. Примеры действий по рассуждению включают понимание влияния требования или конструкции на атрибуты качества, анализ проблем, которые может вызвать конструкция, оценку возможных вариантов решения и оценку компромиссов между решениями.
• Документация — это запись проекта, созданного в процессе создания архитектуры программного обеспечения. Проектирование системы описывается с использованием нескольких представлений, которые часто включают статическое представление, показывающее структуру кода системы, динамическое представление, показывающее действия системы во время выполнения, и представление развертывания, показывающее, как система размещается на оборудовании для выполнения. Представление Крухтена 4+1 предлагает описание часто используемых представлений для документирования архитектуры программного обеспечения; Документирование архитектур программного обеспечения: представления и не только содержит описания типов обозначений, которые можно использовать в описании представления. Примерами деятельности по документированию являются написание спецификации, запись модели проектирования системы, документирование обоснования проекта, разработка точки зрения, документирование представлений.

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

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

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

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

Языки описания архитектуры

Основная статья: Язык описания архитектуры

Язык описания архитектуры (ADL) — это любое средство выражения, используемое для описания архитектуры программного обеспечения ( ISO/IEC/IEEE 42010 ). С 1990-х годов было разработано множество ADL специального назначения, в том числе AADL (стандарт SAE), Wright (разработанный Carnegie Mellon), Acme (разработанный Carnegie Mellon), xADL (разработанный UCI), Darwin (разработанный Имперским колледжем Лондона ). , DAOP-ADL (разработан Университетом Малаги), SBC-ADL (разработан Национальным университетом Сунь Ятсена ) и ByADL (Университет Л'Аквила, Италия).

Точки зрения на архитектуру

Основная статья: Посмотреть модель

Модель архитектурного вида 4+1 .

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

Архитектурные фреймворки

Основная статья: Архитектурная основа

Структура архитектуры охватывает «соглашения, принципы и практику описания архитектур, установленных в конкретной области применения и/или сообществе заинтересованных сторон» ( ISO/IEC/IEEE 42010 ). Структура обычно реализуется с точки зрения одной или нескольких точек зрения или ADL.

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

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

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

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

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

Существует множество признанных архитектурных образцов и стилей, среди них:

• доска
• Клиент-сервер (2-уровневые, 3-уровневые , n -уровневые облачные вычисления демонстрируют этот стиль)
• Компонентный
• Ориентированный на данные
• Управляемый событиями (или неявный вызов )
• Многоуровневая (или многоуровневая архитектура )
• Микросервисная архитектура
• Монолитное приложение
• Одноранговая связь (P2P)
• Трубы и фильтры
• Плагины
• Реактивная архитектура
• Представительская государственная передача (REST)
• Основанный на правилах
• Сервис-ориентированный
• Ничего не разделяемая архитектура
• Космическая архитектура
• Бессерверная архитектура

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

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

Основная статья: Гибкая разработка

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

архитектуры

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

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

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

архитектуры

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

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

Связанные поля

Дизайн

Основная статья: Разработка программного обеспечения

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

Разработка требований

Основная статья: Разработка требований

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

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

Другие типы «архитектуры»

Основные статьи: Архитектура компьютера , Архитектура систем и Архитектура предприятия.

Компьютерная архитектура

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

Бессерверная архитектура

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

Архитектура систем

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

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

Цель архитектуры предприятия — «воплотить бизнес-видение и стратегию в эффективное предприятие». архитектуры предприятия Фреймворки , такие как TOGAF и Zachman Framework , обычно различают разные уровни архитектуры предприятия. Хотя терминология различается от платформы к платформе, многие из них включают, по крайней мере, различие между бизнес- уровнем , прикладным (или информационным ) уровнем и технологическим уровнем . Архитектура предприятия, среди прочего, направлена ​​на согласование между этими уровнями, обычно по принципу «сверху вниз».

См. также

• АрхиМейт
• Архитектурный образец (информатика)
• Антипаттерн
• Атрибутно-ориентированный дизайн
• Модель С4
• Компьютерная архитектура
• Распределенная архитектура управления данными
• Архитектура распределенной реляционной базы данных
• Архитектура систем
• Проектирование систем
• Метод анализа архитектуры программного обеспечения
• Система с таймером

Дальнейшее чтение

• Ричардс, Марк (2020). Основы архитектуры программного обеспечения: инженерный подход . О'Рейли Медиа . ISBN  9781492043454 .
• Лен, Басс (2012). Архитектура программного обеспечения на практике (3-е изд.). Аддисон-Уэсли Профессионал . ISBN  9780321815736 . - В этой книге рассматриваются фундаментальные понятия дисциплины. Тема сосредоточена на достижении качественных показателей системы.
• Клементс, Пол (2010). Документирование архитектуры программного обеспечения: представления и не только (2-е изд.). Аддисон-Уэсли Профессионал . ISBN  9780321552686 . - В этой книге описывается, что такое архитектура программного обеспечения, и показано, как документировать ее в нескольких представлениях, используя UML и другие нотации. В нем также объясняется, как дополнить представления об архитектуре поведением, программным интерфейсом и обоснованной документацией. К книге прилагается вики- сайт, содержащий пример документации по архитектуре программного обеспечения .
• Белл, Майкл (2008). Белл, Майкл (ред.). Сервис-ориентированное моделирование: анализ, проектирование и архитектура сервисов . Уайли. дои : 10.1002/9781119198864 . ISBN  9780470255704 .
• Шан, Тони; Хуа, Винни (октябрь 2006 г.). «Механизм проектирования решений». 2006 10-я Международная конференция IEEE по корпоративным распределенным объектным вычислениям (EDOC'06) . стр. 23–32. дои : 10.1109/EDOC.2006.54 . ISBN  978-0-7695-2558-7 . S2CID   8361936 .
• Гарсас, Хавьер; Пьяттини, Марио (2005). «Онтология знаний в области микроархитектурного проектирования». Программное обеспечение IEEE . 22 (2): 28–33. дои : 10.1109/MS.2005.26 . S2CID   17639072 .
• Фаулер, Мартин (сентябрь 2003 г.). «Кому нужен архитектор?» (PDF) . Программное обеспечение IEEE . 20 (5). дои : 10.1109/MS.2003.1231144 . S2CID   356506 .
• Казман, Рик (май 2003 г.). «Архитектура, проектирование, реализация» (PDF) . Институт программной инженерии . Архивировано (PDF) из оригинала 21 сентября 2015 г. - О различии архитектурного проектирования и рабочего проектирования.
• Крухтен, Филипп (1995). «Архитектурные чертежи – модель архитектуры программного обеспечения «4+1»» (PDF) . Программное обеспечение IEEE . 12 (6): 42–50. arXiv : 2006.04975 . дои : 10.1109/52.469759 . S2CID   219558624 . Архивировано (PDF) из оригинала 13 июня 2006 г.
• Паутассо, Чезаре (2020). Архитектура программного обеспечения: визуальные конспекты лекций . ЛинПаб. п. 689.

Внешние ссылки

• Пояснения к IBM Developerworks
• Сборник определений архитектуры программного обеспечения в Институте программной инженерии (SEI) Университета Карнеги-Меллона (CMU)
• Международная ассоциация ИТ-архитекторов (IASA Global) , ранее известная как Международная ассоциация архитекторов программного обеспечения (IASA)
• SoftwareArchitecturePortal.org - веб-сайт Рабочей группы IFIP 2.10 по архитектуре программного обеспечения.
• SoftwareArchitectures.com – независимый информационный ресурс по дисциплине.
• Архитектура программного обеспечения , глава 1 диссертации Роя Филдинга по REST
• Когда хорошая архитектура становится плохой
• Разработка, основанная на спиральной архитектуре – SDLC, основанный на спиральной модели , направлен на снижение рисков неэффективной архитектуры.
• Примеры из реальной жизни: архитектура программного обеспечения