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

Разработка программного обеспечения
Активность ядер
Парадигмы и модели
Методологии и рамки
Вспомогательные дисциплины
Практики
Инструменты
Стандарты и свод знаний
Глоссарии
Контуры

Архитектура программного обеспечения относится к фундаментальным структурам программная система и дисциплина создания таких структур и систем. Каждая структура включает элементы программного обеспечения, отношения между ними, а также свойства как элементов, так и отношений.[1] В архитектура программной системы - это метафора, аналогичная архитектура здания.[2] Он функционирует как план для системы и проекта разработки, в котором излагаются задачи, которые должны быть выполнены командами разработчиков.[3]

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

Документирование программного обеспечения архитектура облегчает связь между заинтересованные стороны, фиксирует ранние решения о высокоуровневом дизайне и позволяет повторно использовать компоненты дизайна между проектами.[4]:29–35

Объем

Мнения относительно объема программных архитектур расходятся:[5]

  • Структура макроскопической системы: это относится к архитектуре как к высокоуровневому абстракция программной системы, состоящей из набора вычислительных составные части вместе с разъемы которые описывают взаимодействие между этими компонентами.[6]
  • Важные вещи - что бы это ни было: это относится к тому факту, что архитекторы программного обеспечения должны заботиться о тех решениях, которые имеют большое влияние на систему и ее заинтересованные стороны.[7]
  • То, что является основополагающим для понимания системы в ее среде[8]
  • Вещи, которые людям сложно изменить: поскольку проектирование архитектуры происходит в начале жизненного цикла программной системы, архитектор должен сосредоточиться на решениях, которые «должны» быть правильными с первого раза. Следуя этой мысли, проблемы архитектурного проектирования могут стать не архитектурными, если их необратимость будет преодолена.[7]
  • Набор архитектурно-дизайнерских решений: архитектура программного обеспечения не должна рассматриваться просто как набор моделей или структур, она должна включать решения, которые приводят к этим конкретным структурам, и их обоснование.[9] Это понимание привело к серьезным исследованиям архитектуры программного обеспечения. управление знаниями.[10]

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

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

Программная архитектура демонстрирует следующее:

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

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

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

Повторяющиеся стили: Подобно архитектуре здания, дисциплина архитектуры программного обеспечения разработала стандартные способы решения повторяющихся проблем. Эти «стандартные способы» называются разными именами на разных уровнях абстракции. Общие термины для повторяющихся решений - архитектурный стиль,[11]:273–277 тактика[4]:70–72 эталонная архитектура[13][14] и архитектурный образец.[4]:203–205

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

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

Мотивация

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

  • Это дает основу для анализа поведения программных систем до того, как система будет построена.[2] Возможность проверить, что будущая программная система удовлетворяет потребности заинтересованных сторон, не создавая ее, представляет собой существенную экономию затрат и снижение рисков.[16] Для проведения такого анализа был разработан ряд методов, например: АТАМ или создав визуальное представление программной системы.
  • Он обеспечивает основу для повторного использования элементов и решений.[2][4]:35 Полная архитектура программного обеспечения или ее части, такие как индивидуальные архитектурные стратегии и решения, могут быть повторно использованы в нескольких системах, заинтересованным сторонам которых требуются аналогичные атрибуты качества или функциональность, что снижает затраты на проектирование и снижает риск ошибок проектирования.
  • Он поддерживает ранние проектные решения, которые влияют на разработку, развертывание и срок службы системы.[4]:31 Принятие правильных и важных решений на раннем этапе важно для предотвращения графика и перерасход бюджета.
  • Это облегчает общение с заинтересованными сторонами, внося свой вклад в систему, которая лучше удовлетворяет их потребности.[4]:29–31 Общение о сложных системах с точки зрения заинтересованных сторон помогает им понять последствия заявленных ими требований и проектных решений, основанных на них. Архитектура дает возможность сообщать о проектных решениях до внедрения системы, когда их еще относительно легко адаптировать.
  • Это помогает в управлении рисками. Архитектура программного обеспечения помогает снизить риски и вероятность отказа.[11]:18
  • Это позволяет снижение цены. Архитектура программного обеспечения - это средство управления рисками и затратами в сложных ИТ-проектах.[17]

История

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

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

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

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

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

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

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

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

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

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

Архитектурный синтез или дизайн - это процесс создания архитектуры. Учитывая архитектурно значимые требования, определенные анализом, текущее состояние проекта и результаты любых оценочных мероприятий, проект создается и улучшается.[24][4]:311–326

Оценка архитектуры это процесс определения того, насколько хорошо текущий проект или его часть удовлетворяет требованиям, полученным в ходе анализа. Оценка может происходить всякий раз, когда архитектор рассматривает проектное решение, это может происходить после завершения некоторой части проекта, это может происходить после того, как завершен окончательный проект, или это может происходить после того, как система была построена. Некоторые из доступных методов оценки архитектуры программного обеспечения включают: Метод анализа компромиссов в архитектуре (ATAM) и ТАРА.[28] Фреймворки для сравнения методов обсуждаются в таких фреймворках, как Отчет SARA[16] и Обзоры архитектуры: практика и опыт.[29]

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

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

Поддержка архитектуры

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

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

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

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

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

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

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

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

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

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

Основная статья: Посмотреть модель
4 + 1 архитектурный вид.

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

Фреймворки архитектуры

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

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

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

Основная статья: Архитектурный образец

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

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

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

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

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

Некоторые относятся к архитектурным образцам и архитектурным стилям как к одному,[35] некоторые рассматривают стили как специализацию паттернов. Их объединяет то, что шаблоны и стили - это идиомы для использования архитекторами, они «обеспечивают общий язык».[35] или "словарь"[33] для описания классов систем.

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

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

Есть также опасения, что архитектура программного обеспечения приводит к слишком большому Большой дизайн спереди, особенно среди сторонников гибкая разработка программного обеспечения. Был разработан ряд методов, позволяющих уравновесить компромисс между предварительным дизайном и маневренностью.[36] включая гибкий метод DSDM который требует фазы «Основания», во время которой закладывается «ровно достаточное количество» архитектурных основ. Программное обеспечение IEEE Отдельный выпуск посвятил взаимодействию гибкости и архитектуры.

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

Разрушение (или «распад») архитектуры программного обеспечения - это разрыв, наблюдаемый между запланированной и фактической архитектурой программной системы, реализованной в ее реализации.[37] Разрушение архитектуры программного обеспечения происходит, когда решения о реализации либо не полностью соответствуют запланированной архитектуре, либо иным образом нарушают ограничения или принципы этой архитектуры.[2] Разрыв между запланированной и реальной архитектурой иногда понимается в терминах понятия технический долг.

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

Были предложены различные подходы к решению проблемы эрозии. "Эти подходы, которые включают инструменты, методы и процессы, в первую очередь классифицируются на три общие категории, которые пытаются минимизировать, предотвратить и исправить эрозию архитектуры. В рамках этих широких категорий каждый подход далее разбивается, отражая стратегии высокого уровня, принятые для бороться с эрозией. Это процессно-ориентированные методы согласования архитектуры, управление развитием архитектуры, обеспечение соблюдения дизайна архитектуры, связь архитектуры с реализацией, самоадаптация и восстановление архитектуры, состоящие из восстановления, обнаружения и согласования ».[38]

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

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

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

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

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

Дизайн

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

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

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

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

Разработка требований и программную архитектуру можно рассматривать как дополнительные подходы: в то время как программная архитектура нацелена напространство решений 'или' как ', разработка требований обращается к'проблемное пространство 'или' что '.[41] Разработка требований влечет за собой выявление, Переговоры, Технические характеристики, Проверка, документация и управление из требования. И разработка требований, и архитектура программного обеспечения вращаются вокруг акционер заботы, потребности и пожелания.

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

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

Основные статьи: Компьютерная архитектура, Системная архитектура, и Архитектура предприятия
Компьютерная архитектура
Компьютерная архитектура нацелена на внутреннюю структуру компьютерной системы с точки зрения взаимодействующих аппаратных компонентов, таких как ЦПУ - или процессор - автобус и объем памяти.
Системная архитектура
Период, термин системная архитектура изначально был применен к архитектуре системы который состоит из оборудования и программного обеспечения. Основная проблема, которую решает системная архитектура, - это интеграция программного и аппаратного обеспечения в законченное, правильно работающее устройство. В другом распространенном - гораздо более широком - значении, этот термин применяется к архитектуре любой сложной системы, которая может быть технической, социально технический или социальный характер.
Архитектура предприятия
Цель архитектура предприятия заключается в том, чтобы «преобразовать видение бизнеса и стратегию в эффективное предприятие». Архитектура предприятия рамки, Такие как TOGAF и Фреймворк Захмана, обычно различают разные уровни архитектуры предприятия. Хотя терминология различается от структуры к структуре, многие включают, по крайней мере, различие между бизнес слой, заявление (или же Информация ) слой, а технологии слой. Архитектура предприятия направлена, среди прочего, на согласование между этими уровнями, обычно по принципу «сверху вниз».

Смотрите также

Рекомендации

  1. ^ а б c Клементс, Пол; Феликс Бахманн; Лен Басс; Дэвид Гарлан; Джеймс Айверс; Рид Литтл; Пауло Мерсон; Роберт Норд; Джудит Стаффорд (2010). Документирование программных архитектур: взгляды и перспективы, второе издание. Бостон: Эддисон-Уэсли. ISBN  978-0-321-55268-6.
  2. ^ а б c d Perry, D.E .; Вольф, А. (1992). «Основы исследования архитектуры программного обеспечения» (PDF). Примечания по разработке программного обеспечения ACM SIGSOFT. 17 (4): 40. CiteSeerX  10.1.1.40.5174. Дои:10.1145/141874.141884. S2CID  628695.
  3. ^ «Архитектура программного обеспечения». www.sei.cmu.edu. Получено 2018-07-23.
  4. ^ а б c d е ж грамм час я j Бас, Лен; Пол Клементс; Рик Казман (2012). Архитектура программного обеспечения на практике, третье издание. Бостон: Эддисон-Уэсли. ISBN  978-0-321-81573-6.
  5. ^ SEI (2006). «Как вы определяете архитектуру программного обеспечения?». Получено 2012-09-12.
  6. ^ Гарлан и Шоу (1994). «Введение в архитектуру программного обеспечения» (PDF). Получено 2012-09-13.
  7. ^ а б Фаулер, Мартин (2003). «Дизайн - Кому нужен архитектор?». Программное обеспечение IEEE. 20 (5): 11–44. Дои:10.1109 / MS.2003.1231144. S2CID  356506.
  8. ^ ISO / IEC / IEEE 42010: Определение «архитектуры». Iso-architecture.org. Проверено 21 июля 2013.
  9. ^ а б Jansen, A .; Босх, Дж. (2005). «Архитектура программного обеспечения как набор архитектурных дизайнерских решений». 5-я рабочая конференция IEEE / IFIP по архитектуре программного обеспечения (WICSA'05). п. 109. CiteSeerX  10.1.1.60.8680. Дои:10.1109 / WICSA.2005.61. ISBN  978-0-7695-2548-8. S2CID  13492610.
  10. ^ Али Бабар, Мухаммед; Дингсойр, Торгейр; Лаго, Патрисия; ван Влит, Ганс (2009). Управление знаниями архитектуры программного обеспечения. Дордрехт Гейдельберг Лондон Нью-Йорк: Спрингер. ISBN  978-3-642-02373-6.
  11. ^ а б c Джордж Фэрбенкс (2010). Достаточно архитектуры программного обеспечения. Маршалл и Брейнерд.
  12. ^ а б ISO / IEC / IEEE (2011). «ISO / IEC / IEEE 42010: 2011 Системная и программная инженерия - Описание архитектуры». Получено 2012-09-12.
  13. ^ Мюллер, Геррит (20 августа 2007 г.). «Справочник по архитектуре» (PDF). Сайт Гауди. Получено 13 ноября, 2015.
  14. ^ Ангелов, Самуил; Грефен, Пол; Greefhorst, Дэнни (2009). «Классификация эталонных архитектур программного обеспечения: анализ их успеха и эффективности». Proc. WICSA / ECSA 2009: 141–150. CiteSeerX  10.1.1.525.7208. Дои:10.1109 / WICSA.2009.5290800. ISBN  978-1-4244-4984-2. S2CID  10417628.
  15. ^ Брукс младший, Фредерик П. (1975). Мифический человеко-месяц - Очерки программной инженерии. Эддисон-Уэсли. ISBN  978-0-201-00650-6.
  16. ^ а б Оббинк, Х .; Kruchten, P .; Kozaczynski, W .; Postema, H .; Ран, А .; Dominick, L .; Казман, Р .; Hilliard, R .; Tracz, W .; Кахане, Э. (6 февраля 2002 г.). «Отчет об обзоре и оценке архитектуры программного обеспечения (SARA)» (PDF). Получено 1 ноября, 2015.
  17. ^ Поорт, Эльтьо; ван Влит, Ганс (сентябрь 2012 г.). «RCDA: Архитектура как дисциплина управления рисками и затратами». Журнал систем и программного обеспечения. 85 (9): 1995–2013. Дои:10.1016 / j.jss.2012.03.071.
  18. ^ П. Наур; Б. Рэнделл, ред. (1969). «Программная инженерия: отчет конференции, организованной Научным комитетом НАТО, Гармиш, Германия, 7–11 октября 1968 г.» (PDF). Брюссель: НАТО, Отдел по научным вопросам. Получено 2012-11-16.
  19. ^ П. Крухтен; Х. Оббинк; Дж. Стаффорд (2006). «Прошлое, настоящее и будущее архитектуры программного обеспечения». Программное обеспечение IEEE. 23 (2): 22. Дои:10.1109 / MS.2006.59. S2CID  2082927.
  20. ^ Университет Ватерлоо (2006 г.). «Очень краткая история компьютерных наук». Получено 2006-09-23.
  21. ^ IEEE Transactions по разработке программного обеспечения (2006 г.). «Введение в специальный выпуск об архитектуре программного обеспечения». Дои:10.1109 / TSE.1995.10003. Цитировать журнал требует | журнал = (помощь)
  22. ^ Гарлан и Шоу (1994). «Введение в архитектуру программного обеспечения» (PDF). Получено 2006-09-25.
  23. ^ а б Крухтен, П. (2008). «Чем на самом деле занимаются архитекторы программного обеспечения?». Журнал систем и программного обеспечения. 81 (12): 2413–2416. Дои:10.1016 / j.jss.2008.08.025.
  24. ^ а б c Кристин Хофмайстер; Филипп Крюхтен; Роберт Л. Норд; Хенк Оббинк; Александр Ран; Пьер Америка (2007). «Общая модель проектирования архитектуры программного обеспечения, основанная на пяти промышленных подходах». Журнал систем и программного обеспечения. 80 (1): 106–126. Дои:10.1016 / j.jss.2006.05.024.
  25. ^ а б ИСО / МЭК (2011). «ISO / IEC 25010: 2011 Системная и программная инженерия - Требования и оценка качества систем и программного обеспечения (SQuaRE) - Модели качества систем и программного обеспечения». Получено 2012-10-08.
  26. ^ Остервальдер и Пиньер (2004). «Онтология моделей электронного бизнеса» (PDF). Создание ценности на основе моделей электронного бизнеса. С. 65–97. CiteSeerX  10.1.1.9.6922. Дои:10.1016 / B978-075066140-9 / 50006-0. ISBN  9780750661409. S2CID  14177438.
  27. ^ Чен, Ляньпин; Али Бабар, Мухаммед; Нусейбе, Башар (2013). «Характеризация архитектурно значимых требований». Программное обеспечение IEEE. 30 (2): 38–45. Дои:10.1109 / MS.2012.174. HDL:10344/3061. S2CID  17399565.
  28. ^ Вудс, Э. (2012). «Промышленная архитектурная оценка с использованием TARA». Журнал систем и программного обеспечения. 85 (9): 2034–2047. Дои:10.1016 / j.jss.2012.04.055. S2CID  179244.
  29. ^ Maranzano, J. F .; Розсыпал, С. А .; Циммерман, Г. Х .; Warnken, G.W .; Wirth, P.E .; Вайс, Д. М. (2005). «Обзоры архитектуры: практика и опыт». Программное обеспечение IEEE. 22 (2): 34. Дои:10.1109 / MS.2005.28. S2CID  11697335.
  30. ^ Babar, M.A .; Dingsøyr, T .; Lago, P .; Влит, Х. ван (2009). Управление знаниями архитектуры программного обеспечения: теория и практика (ред.), Первое издание. Springer. ISBN  978-3-642-02373-6.
  31. ^ Tang, A .; Han, J .; Васа, Р. (2009). «Обоснование дизайна архитектуры программного обеспечения: аргумент в пользу улучшенной методологической поддержки». Программное обеспечение IEEE. 26 (2): 43. Дои:10.1109 / MS.2009.46. HDL:1959.3/51601. S2CID  12230032.
  32. ^ Крухтен, Филипп (1995). «Архитектурные чертежи - модель архитектуры программного обеспечения« 4 + 1 »» (PDF). Программное обеспечение IEEE. 12 (6): 42–50. arXiv:2006.04975. Дои:10.1109/52.469759.
  33. ^ а б Шоу, Мэри; Гарлан, Дэвид (1996). Архитектура программного обеспечения: перспективы новой дисциплины. Прентис Холл. ISBN  978-0-13-182957-2.
  34. ^ Исследование архитектуры программного обеспечения UCI - Исследование архитектуры программного обеспечения UCI: архитектурные стили. Isr.uci.edu. Проверено 21 июля 2013.
  35. ^ а б Глава 3: Архитектурные узоры и стили. Msdn.microsoft.com. Проверено 21 июля 2013.
  36. ^ Бем, Барри; Тернер, Ричард (2004). Уравновешивание ловкости и дисциплины. Эддисон-Уэсли. ISBN  978-0-321-18612-6.
  37. ^ Терра, Р., М.Т. Валенте, К. Чарнецки и Р.С. Бигонья, «Рекомендации по рефакторингу для предотвращения эрозии архитектуры программного обеспечения», 16-я Европейская конференция по обслуживанию и реинжинирингу программного обеспечения, 2012 г. http://gsd.uwaterloo.ca/sites/default/files/Full%20Text.pdf
  38. ^ de Silva, L .; Баласубраманиам, Д. (2012). «Контроль эрозии архитектуры программного обеспечения: обзор». Журнал систем и программного обеспечения. 85 (1): 132–151. Дои:10.1016 / j.jss.2011.07.036.
  39. ^ Лунгу М. «Восстановление архитектуры программного обеспечения», Университет Лугано, 2008 г. http://www.slideshare.net/mircea.lungu/software-architecture-recovery-in-five-questions-presentation
  40. ^ а б Амнон Х. Иден; Рик Казман (2003). «Реализация архитектурного дизайна» (PDF). Архивировано из оригинал (PDF) на 2007-09-28.
  41. ^ К. Шекаран; Д. Гарлан; М. Джексон; N.R. Мид; К. Поттс; H.B. Рубенштейн (1994). «Роль архитектуры программного обеспечения в разработке требований». Труды Международной конференции IEEE по разработке требований: 239–245. Дои:10.1109 / ICRE.1994.292379. ISBN  978-0-8186-5480-0. S2CID  3129363.
  42. ^ Ремко К. де Бур, Ханс ван Влит (2009). «О схожести требований и архитектуры». Журнал систем и программного обеспечения. 82 (3): 544–550. CiteSeerX  10.1.1.415.6023. Дои:10.1016 / j.jss.2008.11.185.
  43. ^ Башар Нусейбе (2001). «Объединение требований и архитектур» (PDF). Компьютер. 34 (3): 115–119. Дои:10.1109/2.910904.

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

внешняя ссылка