Войти
Архитектура программного обеспечения относится к фундаментальным структурам системы программного обеспечения и дисциплина создания таких структур и систем. Каждая структура включает элементы программного обеспечения, отношения между ними, а также свойства как элементов, так и отношений. Архитектура программной системы - это метафора, аналогичная архитектуре здания. Он функционирует как план для системы и проекта разработки, в котором излагаются задачи, которые должны быть выполнены проектными группами.
Архитектура программного обеспечения заключается в принятии фундаментальных структурных решений, изменение которых после реализации требует больших затрат. Выбор архитектуры программного обеспечения включает конкретные структурные варианты из возможностей проекта программного обеспечения. Например, системы, управляющие ракетой-носителем Space Shuttle, должны были быть очень быстрыми и очень надежными. Следовательно, необходимо выбрать соответствующий язык вычислений в реальном времени. Кроме того, чтобы удовлетворить потребность в надежности, можно было бы выбрать несколько дублирующих и независимо созданных копий программы и запускать эти копии на независимом оборудовании при одновременной проверке результатов.
Документирование архитектуры программного обеспечения облегчает общение между заинтересованными сторонами, фиксирует ранние решения по высокоуровневому дизайну и позволяет повторно использовать компоненты дизайна между проектами.
Относительно объема программных архитектур мнения расходятся:
Нет четкого различия между архитектурой программного обеспечения и проектированием и разработкой требований (см. Связанные поля ниже). Все они являются частью «цепочки намерений» от намерений высокого уровня до подробностей низкого уровня.
Архитектура программного обеспечения демонстрирует следующее:
Множество заинтересованных сторон: программные системы должны обслуживать множество заинтересованных сторон, таких как руководители предприятий, владельцы, пользователи и операторы. У всех этих заинтересованных сторон есть свои опасения по поводу системы. Уравновешивание этих проблем и демонстрация того, что они решены, - это часть проектирования системы. Это означает, что архитектура подразумевает работу с широким кругом проблем и заинтересованных сторон и носит междисциплинарный характер.
Разделение проблем : общепринятый способ уменьшения сложности для архитекторов - разделение проблем, лежащих в основе дизайна. Документация по архитектуре показывает, что все проблемы заинтересованных сторон решаются путем моделирования и описания архитектуры с разных точек зрения, связанных с различными проблемами заинтересованных сторон. Эти отдельные описания называются архитектурными видами (см., Например, модель архитектурного вида 4 + 1 ).
Нацеленность на качество: классический дизайн программного обеспечения подходы (например, Структурированное программирование Джексона ) основывались на требуемой функциональности и потоке данных через систему, но текущее понимание заключается в том, что архитектура программной системы более тесно связана с ее атрибутами качества, такими как отказоустойчивость, обратная совместимость, расширяемость, надежность, ремонтопригодность, доступность, безопасность, удобство использования и другие подобные - возможности. Обеспокоенность заинтересованных сторон часто выражается в требованиях к этим атрибутам качества, которые по-разному называются нефункциональными требованиями, дополнительными функциональными требованиями, поведенческими требованиями или требованиями атрибутов качества.
Повторяющиеся стили: подобно архитектуре здания, дисциплина архитектуры программного обеспечения разработала стандартные способы решения повторяющихся проблем. Эти «стандартные способы» называются разными именами на разных уровнях абстракции. Общие термины для повторяющихся решений: архитектурный стиль, тактика, эталонная архитектура и архитектурный шаблон.
Концептуальная целостность: термин, введенный Фредом Бруксом в Мифический человеко-месяц для обозначения идеи о том, что архитектура программной системы представляет собой общее видение того, что она должна делать и как она должна это делать. Это видение следует отделить от его реализации. Архитектор берет на себя роль «хранителя видения», следя за тем, чтобы дополнения к системе соответствовали архитектуре, тем самым сохраняя концептуальную целостность.
Когнитивные ограничения: наблюдение Впервые в работе 1967 года программист Мелвин Конвей указал, что организации, проектирующие системы, вынуждены производить проекты, являющиеся копиями коммуникационных структур этих организаций. Как и в случае с концептуальной целостностью, именно Фред Брукс представил ее более широкой аудитории, когда он процитировал статью и идею в своей элегантной классической книге «Мифический человеко-месяц», назвав ее «законом Конвея».
Архитектура программного обеспечения - это «интеллектуально понятная» абстракция сложной системы. Эта абстракция дает ряд преимуществ:
Сравнение между проектированием программного обеспечения и (гражданской) архитектурой было впервые проведено в конце 1960-х, но термин «архитектура программного обеспечения» не получил широкого распространения до 1990-х годов. В области информатики с самого начала возникали проблемы, связанные со сложностью. Ранее проблемы сложности решались разработчиками путем выбора правильных структур данных, разработки алгоритмов и применения концепции разделения проблем. Хотя термин «программная архитектура» является относительно новым для отрасли, фундаментальные принципы этой области время от времени применялись пионерами программной инженерии с середины 1980-х годов. Ранние попытки описать и объяснить архитектуру программного обеспечения системы были неточными и дезорганизованными, часто характеризовались набором прямоугольных диаграмм.
Архитектура программного обеспечения, поскольку концепция возникла в исследованиях Эдсгера. Дейкстра в 1968 году и Давид Парнас в начале 1970-х годов. Эти ученые подчеркнули, что структура программной системы имеет значение, а правильная структура имеет решающее значение. В течение 1990-х годов предпринимались согласованные усилия по определению и систематизации фундаментальных аспектов дисциплины, при этом исследовательская работа была сосредоточена на архитектурных стилях (шаблоны ), языках описания архитектуры, документации по архитектуре. и формальные методы.
Исследовательские учреждения сыграли заметную роль в развитии архитектуры программного обеспечения как дисциплины. Мэри Шоу и Дэвид Гарлан из Карнеги-Меллон написали книгу под названием «Архитектура программного обеспечения: перспективы новой дисциплины» в 1996 году, в которой продвигались такие концепции архитектуры программного обеспечения, как компоненты, соединители и стили. Усилия Института исследований программного обеспечения Калифорнийского университета в Ирвине в исследованиях архитектуры программного обеспечения направлены в первую очередь на архитектурные стили, языки описания архитектуры и динамические архитектуры.
IEEE 1471 -2000, «Рекомендуемая практика для описания архитектуры программно-интенсивных систем», был первым официальным стандартом в области архитектуры программного обеспечения. В 2007 году он был принят ISO как ISO / IEC 42010: 2007. В ноябре 2011 года стандарт IEEE 1471–2000 был заменен ISO / IEC / IEEE 42010: 2011, «Системная и программная инженерия - Описание архитектуры» (совместно опубликовано IEEE и ISO).
В то время как в IEEE 1471 архитектура программного обеспечения представляла собой архитектуру «программно-интенсивных систем», определяемых как «любая система, в которой программное обеспечение оказывает существенное влияние на проектирование, построение, развертывание и развитие системы как системы. в целом », издание 2011 года идет дальше, включая определения системы в соответствии с ISO / IEC 15288 и ISO / IEC 12207, которые охватывают не только аппаратное и программное обеспечение, но также: люди, процессы, процедуры, оборудование, материалы и природные объекты ". Это отражает взаимосвязь между архитектурой программного обеспечения, архитектурой предприятия и архитектурой решения.
Архитектор программного обеспечения выполняет множество действий. Архитектор программного обеспечения обычно работает с руководителями проектов, обсуждает архитектурно значимые требования с заинтересованными сторонами, проектирует архитектуру программного обеспечения, оценивает дизайн, общается с дизайнерами и заинтересованными сторонами, документирует архитектурный проект и многое другое. В разработке архитектуры программного обеспечения есть четыре основных направления деятельности. Эти основные архитектурные действия выполняются итеративно и на разных этапах начального жизненного цикла разработки программного обеспечения, а также на протяжении эволюции системы.
Архитектурный анализ - это процесс понимания среды, в которой будет работать предлагаемая система, и определения требований к системе. Входные данные или требования к аналитической деятельности могут исходить от любого количества заинтересованных сторон и включать такие элементы, как:
Результатами аналитической деятельности являются те требования, которые оказывают измеримое влияние на архитектуру программной системы, называемые архитектурно значимыми требованиями.
Архитектурный синтез или проектирование - это процесс создания архитектуры. Учитывая архитектурно значимые требования, определенные анализом, текущее состояние проекта и результаты любых действий по оценке, проект создается и улучшается.
Оценка архитектуры - это процесс определения того, насколько хорошо текущий проект или часть его удовлетворяет требованиям, полученным в ходе анализа. Оценка может происходить всякий раз, когда архитектор рассматривает проектное решение, это может происходить после завершения некоторой части проекта, это может происходить после того, как завершен окончательный дизайн, или это может происходить после того, как система была построена. Некоторые из доступных методов оценки архитектуры программного обеспечения включают метод анализа компромисса архитектуры (ATAM) и TARA. Структуры для сравнения методов обсуждаются в таких структурах, как Отчет SARA и Обзор архитектуры: практика и опыт.
Эволюция архитектуры - это процесс поддержки и адаптации существующей архитектуры программного обеспечения для соответствия изменениям требований и среды. Поскольку программная архитектура обеспечивает фундаментальную структуру программной системы, ее развитие и обслуживание обязательно повлияют на ее фундаментальную структуру. Таким образом, эволюция архитектуры связана с добавлением новых функций, а также поддержанием существующих функций и поведения системы.
Архитектура требует критически важных вспомогательных действий. Эти вспомогательные действия выполняются на протяжении всего процесса базовой архитектуры программного обеспечения. Они включают в себя управление знаниями и коммуникацию, конструкторское обоснование и принятие решений, а также документацию.
Действия по поддержке архитектуры программного обеспечения выполняются во время основных действий по архитектуре программного обеспечения. Эти вспомогательные действия помогают архитектору программного обеспечения выполнять анализ, синтез, оценку и развитие. Например, архитектор должен собирать знания, принимать решения и документировать на этапе анализа.
Архитектура программного обеспечения Описание включает в себя принципы и методы моделирования и представления архитектур с использованием таких механизмов, как языки описания архитектуры, точки зрения на архитектуру и структуры архитектуры.
Язык описания архитектуры (ADL) - это любое средство выражения, используемое для описания архитектуры программного обеспечения (ISO / IEC / IEEE 42010 ). Многие специальные ADL были разработаны с 1990-х годов, в том числе AADL (стандарт SAE), Wright (разработан Карнеги-Меллоном) (разработан Карнеги-Меллоном), xADL (разработан UCI), Darwin (разработан Imperial College London ), DAOP-ADL (разработан Университетом Малаги), SBC-ADL (разработан Национальным университетом Сунь Ятсена ) и (Университет Аквилы, Италия).
Модель архитектурного представления 4 + 1.Описание архитектуры программного обеспечения обычно организовано в представления, которые аналогичны различным типам чертежей Сделано в здании архитектура. Каждое представление обращается к набору системных проблем, следуя соглашениям своей точки зрения, где точка зрения - это спецификация, которая описывает нотации, методы моделирования и анализа для использования в представлении, которое выражает рассматриваемую архитектуру с точки зрения заданного набора. заинтересованных сторон и их озабоченности (ISO / IEC / IEEE 42010 ). Точка зрения определяет не только сформулированные проблемы (т.е. подлежащие рассмотрению), но и представление, используемые типы моделей, используемые соглашения и любые правила согласованности (соответствия) для обеспечения согласованности представления с другими представлениями.
Структура архитектуры охватывает «соглашения, принципы и практики для описания архитектур, установленных в определенной области приложения и / или сообществе заинтересованных сторон» (ISO / IEC / IEEE 42010 ). Структура обычно реализуется в терминах одной или нескольких точек зрения или ADL.
Архитектурный шаблон - это общее многократно используемое решение часто встречающейся проблемы в архитектуре программного обеспечения в заданном контексте. Архитектурные шаблоны часто документируются как программные шаблоны проектирования.
Следуя традиционной архитектуре зданий, «программный архитектурный стиль» - это особый метод строительства, характеризующийся особенностями, которые делают его заметным »(архитектурный стиль ).
Архитектурный стиль определяет: семейство систем с точки зрения структурной организации; словарь компонентов и соединителей с ограничениями на то, как они могут быть объединены.
Архитектурные стили - это повторно используемые «пакеты» проектных решений и ограничений, которые применяются к архитектуре для достижения выбранных желаемых качеств.
Существует множество признанных архитектурных шаблонов и стилей, среди них:
Некоторые рассматривают архитектурные шаблоны и архитектурные стили как одно и то же, некоторые рассматривают стили как специализации шаблонов. Их объединяет то, что шаблоны и стили - это идиомы для использования архитекторами, они «обеспечивают общий язык» или «словарь» для описания классов систем.
Существуют также опасения, что архитектура программного обеспечения приводит к слишком большому большому дизайну заранее, особенно среди сторонников гибкой разработки программного обеспечения. Был разработан ряд методов, позволяющих уравновесить компромисс между предварительным проектированием и гибкостью, в том числе метод agile DSDM, который предусматривает фазу «Основы», на которой закладывается «ровно столько» архитектурных основ. IEEE Software посвятил специальный выпуск взаимодействию гибкости и архитектуры.
Разрушение (или «распад») архитектуры программного обеспечения относится к разрыву, наблюдаемому между запланированной и фактической архитектурой программной системы, реализованной в ее реализации. Разрушение архитектуры программного обеспечения происходит, когда решения о реализации либо не полностью соответствуют запланированной архитектуре, либо иным образом нарушают ограничения или принципы этой архитектуры. Разрыв между запланированной и фактической архитектурами иногда понимается в терминах понятия технического долга.
. В качестве примера рассмотрим строго многоуровневую систему, где каждый уровень может использовать только услуги, предоставляемые слой сразу под ним. Любой компонент исходного кода, который не соблюдает это ограничение, представляет собой нарушение архитектуры. Если не исправить, такие нарушения могут превратить архитектуру в монолитный блок, что отрицательно скажется на понятности, ремонтопригодности и эволюционируемости.
Для решения проблемы эрозии были предложены различные подходы. "Эти подходы, которые включают инструменты, методы и процессы, в первую очередь классифицируются на три общие категории, которые пытаются минимизировать, предотвратить и исправить эрозию архитектуры. В рамках этих широких категорий каждый подход далее разбивается, отражая стратегии высокого уровня, принятые для Это методы согласования архитектуры, ориентированной на процесс, управление развитием архитектуры, обеспечение соблюдения дизайна архитектуры, связь архитектуры с реализацией, самоадаптация и методы восстановления архитектуры, состоящие из восстановления, обнаружения и согласования. "
Есть два основные методы обнаружения архитектурных нарушений: модели отражения и предметно-ориентированные языки. Методы модели рефлексии (RM) сравнивают высокоуровневую модель, предоставленную архитекторами системы, с реализацией исходного кода. Также существуют предметно-ориентированные языки с акцентом на определение и проверку архитектурных ограничений.
Восстановление архитектуры программного обеспечения (или реконструкция, или обратное проектирование ) включает в себя методы, приемы и процессы для раскрытия архитектуры программной системы на основе доступной информации, включая его реализацию и документацию. Восстановление архитектуры часто необходимо для принятия обоснованных решений перед лицом устаревшей или устаревшей документации и эрозии архитектуры : решения по внедрению и обслуживанию, отклоняющиеся от предполагаемой архитектуры. Существуют практики восстановления архитектуры программного обеспечения как статический анализ программы. Это часть вопросов, охватываемых практикой программный интеллект.
Архитектура - это дизайн, но не весь дизайн является архитектурным. На практике архитектор - это тот, кто проводит грань между архитектурой программного обеспечения (архитектурный проект) и детальным проектированием (неархитектурный дизайн). Не существует правил или рекомендаций, подходящих для всех случаев, хотя были попытки формализовать различие. Согласно гипотезе о намерении / местонахождении, различие между архитектурным и детальным проектированием определяется критерием локальности, согласно которому утверждение о разработке программного обеспечения является нелокальным (архитектурным) тогда и только тогда, когда удовлетворяющая ему программа может быть расширена до программа, которая этого не делает. Например, стиль клиент-сервер является архитектурным (стратегическим), потому что программа, построенная на этом принципе, может быть расширена в программу, которая не является клиент-серверной, например, путем добавления однорангового узла. -to-peer узлов.
Разработка требований и архитектура программного обеспечения могут рассматриваться как взаимодополняющие подходы: в то время как архитектура программного обеспечения ориентирована на «область решений » или «как», разработка требований обращается к «проблемное пространство » или «что». Разработка требований включает в себя выявление, согласование, спецификацию, проверку, документацию и управление из требований. И разработка требований, и архитектура программного обеспечения вращаются вокруг интересов, потребностей и пожеланий заинтересованных сторон.
Существует значительное совпадение между разработкой требований и архитектурой программного обеспечения, о чем свидетельствует, например, исследование пяти методов архитектуры промышленного программного обеспечения, в котором делается вывод, что «входные данные (цели, ограничения и т. Д.) Обычно плохо определены, и могут быть обнаружены или лучше поняты только по мере того, как архитектура начинает проявляться »и что, хотя« большинство архитектурных проблем выражаются в виде требований к системе, они также могут включать обязательные проектные решения ». Короче говоря, требуемое поведение влияет на архитектуру решения, которая, в свою очередь, может предъявлять новые требования. Такие подходы, как модель Twin Peaks, нацелены на использование синергетического отношения между требованиями и архитектурой.
 | Wikimedia Commons has media related to Software architecture. |
 | Wikiquote has quotations related to: Software architecture |
.
