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

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

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

Документирование архитектуры программного обеспечения облегчает общение между заинтересованными сторонами , фиксирует ранние решения по высокоуровневому дизайну и позволяет повторно использовать компоненты дизайна между проектами. ^{[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] Для выполнения такого анализа был разработан ряд методов, таких как ATAM или создание визуального представления программной системы.
• Он обеспечивает основу для повторного использования элементов и решений. ^{[2] [4] : 35} Полная архитектура программного обеспечения или ее части, такие как индивидуальные архитектурные стратегии и решения, могут быть повторно использованы в нескольких системах, заинтересованным сторонам которых требуются аналогичные атрибуты качества или функциональность, что снижает затраты на проектирование и снижает риск проектирования. ошибки.
• Он поддерживает ранние проектные решения, которые влияют на разработку, развертывание и срок службы системы. ^{[4] : 31} Принятие своевременных и важных решений важно для предотвращения перерасхода графика и бюджета .
• Это облегчает общение с заинтересованными сторонами, внося свой вклад в систему, которая лучше удовлетворяет их потребности. ^{[4] : 29–31} Информирование о сложных системах с точки зрения заинтересованных сторон помогает им понять последствия заявленных ими требований и проектных решений, основанных на них. Архитектура дает возможность сообщать о проектных решениях до внедрения системы, когда их еще относительно легко адаптировать.
• Это помогает в управлении рисками. Архитектура программного обеспечения помогает снизить риски и вероятность отказа. ^{[11] : 18}
• Это позволяет снизить затраты . Архитектура программного обеспечения - это средство управления рисками и затратами в сложных ИТ-проектах. ^[17]

История [ править ]

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

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

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

IEEE 1471-2000, «Рекомендуемая практика для описания архитектуры программно-интенсивных систем», был первым официальным стандартом в области архитектуры программного обеспечения. В 2007 году он был принят ISO как ISO / IEC 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) и TARA. ^[28] Структуры для сравнения методов обсуждаются в таких структурах, как Отчет SARA ^[16] и Обзоры архитектуры: практика и опыт . ^[29]

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

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

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

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

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

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

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

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

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

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

Точки зрения на архитектуру [ править ]

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

Фреймворки архитектуры [ править ]

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

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

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

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

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

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

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

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

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

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

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

Разрушение архитектуры программного обеспечения [ править ]

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

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

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

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

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

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

Связанные поля [ править ]

Дизайн [ править ]

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

Разработка требований [ править ]

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

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

Другие типы «архитектуры» [ править ]

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

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

Системная архитектура

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

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

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

См. Также [ править ]

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

Ссылки [ править ]

Дальнейшее чтение [ править ]

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

Внешние ссылки [ править ]

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

В Wikiquote есть цитаты, связанные с: Архитектура программного обеспечения

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