stringtranslate.com

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

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

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

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

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

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

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

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

Объем

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

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

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

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

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

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

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

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

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

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

Мотивация

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

История

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

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

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

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

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

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

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

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

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

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

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

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

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

Деятельность по поддержке архитектуры

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

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

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

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

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

Язык описания архитектуры (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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дизайн

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

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

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

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

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

Компьютерная архитектура
Компьютерная архитектура ориентирована на внутреннюю структуру компьютерной системы с точки зрения взаимодействия аппаратных компонентов, таких как ЦП (или процессор), шина и память .
Бессерверная архитектура
Бессерверная архитектура — это парадигма облачных вычислений, которую часто неправильно понимают как бессерверную. По сути, это перекладывает обязанности по управлению сервером с разработчиков на поставщиков облачных услуг. Это позволяет предприятиям запускать свой серверный код в облачной инфраструктуре, устраняя необходимость в управлении физическим сервером. Событийно-ориентированный подход бессерверной архитектуры основан на небольших функциях, специфичных для конкретных задач, которые выполняются по требованию. Эти функции известны как «Функция как услуга» (FaaS) и обеспечивают экономическую эффективность за счет модели выставления счетов с оплатой по мере использования и динамического масштабирования ресурсов в зависимости от потребностей приложений. [44] [ нужен лучший источник ]
Архитектура систем
Термин «системная архитектура» первоначально применялся к архитектуре систем , состоящих как из аппаратного, так и из программного обеспечения . Основной задачей, решаемой системной архитектурой, является интеграция программного и аппаратного обеспечения в целостное, правильно работающее устройство. В другом, гораздо более широком, значении этот термин применяется к архитектуре любой сложной системы, которая может иметь техническую, социотехническую или социальную природу.
Архитектура предприятия
Цель архитектуры предприятия — «воплотить бизнес-видение и стратегию в эффективное предприятие». Фреймворки архитектуры предприятия , такие как TOGAF и Zachman Framework , обычно различают разные уровни архитектуры предприятия. Хотя терминология различается от платформы к платформе, многие из них включают, по крайней мере, различие между бизнес- уровнем , прикладным (или информационным ) уровнем и технологическим уровнем . Архитектура предприятия, среди прочего, направлена ​​на согласование между этими уровнями, обычно по принципу «сверху вниз».

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

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

  1. ^ abc Клементс, Пол; Феликс Бахманн; Лен Басс ; Дэвид Гарлан; Джеймс Айверс; Рид Литтл; Пауло Мерсон; Роберт Норд; Джудит Стаффорд (2010). Документирование архитектур программного обеспечения: виды и не только, второе издание . Бостон: Аддисон-Уэсли. ISBN 978-0-321-55268-6.
  2. ^ «Архитектура программного обеспечения». www.sei.cmu.edu . Проверено 23 июля 2018 г.
  3. ^ abcd Перри, Делавэр; Вольф, Алабама (1992). «Основы изучения архитектуры программного обеспечения» (PDF) . Заметки по разработке программного обеспечения ACM SIGSOFT . 17 (4): 40. CiteSeerX 10.1.1.40.5174 . дои : 10.1145/141874.141884. S2CID  628695. 
  4. ^ abcdefghij Басс, Лен; Пол Клементс; Рик Казман (2012). Архитектура программного обеспечения на практике, третье издание . Бостон: Аддисон-Уэсли. ISBN 978-0-321-81573-6.
  5. ^ СЭИ (2006). «Как вы определяете архитектуру программного обеспечения?» . Проверено 12 сентября 2012 г.
  6. ^ Гарлан и Шоу (1994). «Введение в архитектуру программного обеспечения» (PDF) . Проверено 13 сентября 2012 г.
  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. ^ Аб Янсен, А.; Бош, Дж. (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). Управление знаниями об архитектуре программного обеспечения . Дордрехт Гейдельберг Лондон Нью-Йорк: Springer. ISBN 978-3-642-02373-6.
  11. ^ abc Джордж Фэрбенкс (2010). Достаточно архитектуры программного обеспечения . Маршалл и Брейнерд.
  12. ^ ab ISO/IEC/IEEE (2011). «ISO/IEC/IEEE 42010:2011 Разработка систем и программного обеспечения. Описание архитектуры» . Проверено 12 сентября 2012 г.
  13. ↑ Мюллер, Геррит (20 августа 2007 г.). «Букварь по эталонной архитектуре» (PDF) . Сайт Гауди . Архивировано (PDF) из оригинала 19 декабря 2011 г. Проверено 13 ноября 2015 г.
  14. ^ Ангелов, С.; Грефен П.; Грифхорст, Д. (2009). «Классификация эталонных архитектур программного обеспечения: анализ их успеха и эффективности». 2009 Совместная рабочая конференция IEEE/IFIP по архитектуре программного обеспечения и Европейская конференция по архитектуре программного обеспечения. IEEE. стр. 141–150. doi : 10.1109/WICSA.2009.5290800. ISBN 978-1-4244-4984-2. Проверено 15 декабря 2023 г.
  15. ^ Брукс, Фредерик П. младший (1975). Мифический человеко-месяц – Очерки программной инженерии . Аддисон-Уэсли. ISBN 978-0-201-00650-6.
  16. ^ аб Оббинк, Х.; Крухтен, П.; Козачинский, В.; Постема, Х.; Ран, А.; Доминик, Л.; Казман Р.; Хиллиард, Р.; Трач, В.; Кахане, Э. (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) . Брюссель: НАТО, Отдел по научным вопросам. Архивировано (PDF) из оригинала 7 июня 2003 г. Проверено 16 ноября 2012 г.
  19. ^ П. Крухтен; Х. Оббинк; Дж. Стаффорд (2006). «Прошлое, настоящее и будущее архитектуры программного обеспечения». Программное обеспечение IEEE . 23 (2): 22. doi :10.1109/MS.2006.59. S2CID  2082927.
  20. ^ Университет Ватерлоо (2006). «Очень краткая история информатики» . Проверено 23 сентября 2006 г.
  21. ^ «Введение в специальный выпуск по архитектуре программного обеспечения». IEEE.org . 2006. doi :10.1109/TSE.1995.10003.
  22. ^ Гарлан и Шоу (1994). «Введение в архитектуру программного обеспечения» (PDF) . Проверено 25 сентября 2006 г.
  23. ^ Аб Крухтен, П. (2008). «Чем на самом деле занимаются архитекторы программного обеспечения?». Журнал систем и программного обеспечения . 81 (12): 2413–2416. дои : 10.1016/j.jss.2008.08.025.
  24. ^ abc Кристина Хофмайстер; Филипп Крухтен; Роберт Л. Норд; Хенк Оббинк; Александр Ран; Пьер Америка (2007). «Общая модель проектирования архитектуры программного обеспечения, основанная на пяти промышленных подходах». Журнал систем и программного обеспечения . 80 (1): 106–126. дои : 10.1016/j.jss.2006.05.024.
  25. ^ ab ISO/IEC (2011). «ISO/IEC 25010:2011 Разработка систем и программного обеспечения. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модели качества систем и программного обеспечения» . Проверено 8 октября 2012 г.
  26. ^ Остервальдер и Пиньёр (2004). «Онтология для моделей электронного бизнеса» (PDF) . Создание стоимости на основе моделей электронного бизнеса . стр. 65–97. CiteSeerX 10.1.1.9.6922 . дои : 10.1016/B978-075066140-9/50006-0. ISBN  9780750661409. S2CID  14177438. Архивировано из оригинала (PDF) 17 ноября 2018 г.
  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. ^ Маранцано, Дж. Ф.; Розсыпаль, С.А.; Циммерман, Г.Х.; Варнкен, ГВ; Вирт, ЧП; Вайс, DM (2005). «Обзоры архитектуры: практика и опыт». Программное обеспечение IEEE . 22 (2): 34. doi :10.1109/MS.2005.28. S2CID  11697335.
  30. ^ Бабар, Массачусетс; Дингсойр, Т.; Лаго, П.; Влит, Х. ван (2009). Управление знаниями об архитектуре программного обеспечения: теория и практика (ред.), первое издание . Спрингер. ISBN 978-3-642-02373-6.
  31. ^ Тан, А.; Хан, Дж.; Васа, Р. (2009). «Обоснование проектирования архитектуры программного обеспечения: аргументы в пользу улучшения методологической поддержки». Программное обеспечение IEEE . 26 (2): 43. doi :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. S2CID  219558624.
  33. ^ Аб Шоу, Мэри; Гарлан, Дэвид (1996). Архитектура программного обеспечения: взгляды на новую дисциплину . Прентис Холл. ISBN 978-0-13-182957-2.
  34. ^ Исследование архитектуры программного обеспечения UCI - Исследование архитектуры программного обеспечения UCI: архитектурные стили. Isr.uci.edu. Проверено 21 июля 2013 г.
  35. ^ ab Глава 3: Архитектурные образцы и стили. Msdn.microsoft.com. Проверено 21 июля 2013 г.
  36. ^ Бём, Барри; Тернер, Ричард (2004). Баланс между ловкостью и дисциплиной . Аддисон-Уэсли. ISBN 978-0-321-18612-6.
  37. ^ Терра, Р., М.Т. Валенте, К. Чарнеки и Р.С. Бигонья, «Рекомендации по рефакторингу для обращения вспять эрозии архитектуры программного обеспечения», 16-я Европейская конференция по обслуживанию и реинжинирингу программного обеспечения, 2012. http://gsd.uwaterloo.ca/sites/ по умолчанию/файлы/Полный%20Text.pdf
  38. ^ де Сильва, Л.; Баласубраманиам, Д. (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) 28 сентября 2007 г.
  41. ^ К. Шекаран; Д. Гарлан; М. Джексон; Н. Р. Мид; К. Поттс; Х. Б. Рубинштейн (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. Архивировано (PDF) из оригинала 7 сентября 2012 г.
  44. ^ Компания DashDevs | Разработка финтех-программ. «Как использовать бессерверную архитектуру | DashDevs». Как использовать бессерверную архитектуру | DashDevs . Проверено 28 августа 2023 г.

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

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

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