Лекция
Привет, Вы узнаете о том , что такое архитектура программного обеспечения, Разберем основные их виды и особенности использования. Еще будет много подробных примеров и описаний. Для того чтобы лучше понимать что такое архитектура программного обеспечения , настоятельно рекомендую прочитать все из категории Разработка программного обеспечения и информационных систем.
архитектура программного обеспечения относится к фундаментальным структурам программной системы и дисциплине создания таких структур и систем. Каждая структура включает элементы программного обеспечения, отношения между ними, а также свойства как элементов, так и отношений. архитектура программной системы является метафорой, аналогично архитектуре здания. Он функционирует как план для системы и разрабатываемого проекта, в котором излагаются задачи, которые должны быть выполнены проектными группами.
Архитектура программного обеспечения заключается в принятии фундаментальных структурных решений, изменение которых после реализации требует больших затрат. Выбор архитектуры программного обеспечения включает конкретные структурные варианты из возможностей в разработке программного обеспечения . Например, системы, управляющие ракетой-носителем " Спейс Шаттл", должны были быть очень быстрыми и очень надежными. Следовательно, необходимо выбрать соответствующий язык вычислений в реальном времени . Кроме того, чтобы удовлетворить потребность в надежности, можно было бы выбрать несколько дублирующих и независимо создаваемых копий программы и запускать эти копии на независимом оборудовании при одновременной проверке результатов.
Документирование архитектуры программного обеспечения облегчает общение между заинтересованными сторонами , фиксирует ранние решения по высокоуровневому дизайну и позволяет повторно использовать компоненты дизайна между проектами.
Архитектурный шаблон — это общее и повторяющееся решение часто возникающей проблемы архитектуры приложений в пределах заданного контекста. Архитектурные шаблоны схожи с шаблонами программного дизайна, однако имеют более широкий охват.
Архитектура программного обеспечения (англ. software architecture) — это структура программы или вычислительной системы, которая включает программные компоненты, видимые снаружи свойства этих компонентов, а также отношения между ними . Этот термин также относится к документированию архитектуры программного обеспечения . Документирование архитектуры ПО упрощает процесс коммуникации между стейкхолдерами, позволяет зафиксировать принятые на ранних этапах проектирования решения о высокоуровневом дизайне системы и позволяет использовать компоненты этого дизайна и шаблоны повторно в других проектах.
Общепринятого определения «архитектуры программного обеспечения» не существует. Так, сайт Software Engineering Institute приводит более 150 определений этого понятия
Архитектура программного обеспечения (англ. software architecture) — совокупность важнейших решений об организации программной системы. Архитектура включает:
Область компьютерных наук с момента своего образования столкнулась с проблемами, связанными со сложностью программных систем. Ранее проблемы сложности решались разработчиками путем правильного выбора структур данных, разработки алгоритмов и применения концепции разграничения полномочий. Хотя термин «архитектура программного обеспечения» является относительно новым для индустрии разработки ПО, фундаментальные принципы этой области неупорядоченно применялись пионерами разработки ПО начиная с середины 1980-х. Первые попытки осознать и объяснить программную архитектуру системы были полны неточностей и страдали от недостатка организованности, часто это была просто диаграмма из блоков, соединенных линиями. В 1990-е годы наблюдается попытка определить и систематизировать основные аспекты данной дисциплины. Первоначальный набор шаблонов проектирования, стилей дизайна, передового опыта (best practices), языков описания и формальная логика были разработаны в течение этого времени.
Основополагающей идеей дисциплины программной архитектуры является идея снижения сложности системы путем абстракции и разграничения полномочий. На сегодняшний день до сих пор нет согласия в отношении четкого определения термина «архитектура программного обеспечения».
Являясь в настоящий момент своего развития дисциплиной без четких правил о «правильном» пути создания системы, проектирование архитектуры ПО все еще является смесью науки и искусства. Аспект «искусства» заключается в том, что любая коммерческая система подразумевает наличие применения или миссии. То, какие ключевые цели имеет система, описывается с помощью сценариев как нефункциональные требования к системе, также известные как атрибуты качества, определяющих, как будет вести себя система. Атрибуты качества системы включают в себя отказоустойчивость, сохранение обратной совместимости, расширяемость, надежность, пригодность к сервисному обслуживанию (maintainability), доступность, безопасность, удобство использования, а также другие качества. С точки зрения пользователя программной архитектуры, программная архитектура дает направление для движения и решения задач, связанных со специальностью каждого такого пользователя, например, заинтересованного лица, разработчика ПО, группы поддержки ПО, специалиста по сопровождению ПО, специалиста по развертыванию ПО, тестера, а также конечных пользователей. В этом смысле архитектура программного обеспечения на самом деле объединяет различные точки зрения на систему. Тот факт, что эти несколько различных точек зрения могут быть объединены в архитектуре программного обеспечения, является аргументом в защиту необходимости и целесообразности создания архитектуры ПО еще до этапа разработки ПО.
Начало архитектуре программного обеспечения как концепции было положено в научно-исследовательской работе Эдсгера Дейкстры в 1968 году и Дэвида Парнаса в начале 1970-х. Эти ученые подчеркнули, что структура системы ПО имеет важное значение, и что построение правильной структуры — критически важно. Популярность изучения этой области возросла с начала 1990-х годов вместе с научно-исследовательской работой по исследованию архитектурных стилей (шаблонов), языков описания архитектуры, документирования архитектуры, и формальных методов.
В развитии архитектуры программного обеспечения как дисциплины играют важную роль научно-исследовательские учреждения. Мэри Шоу и Дэвид Гэрлан из университета Carnegie Mellon написали книгу под названием «Архитектура программного обеспечения: перспективы новой дисциплины в 1996 году», в которой выдвинули концепции архитектуры программного обеспечения, такие как компоненты, соединители (connectors), стили и так далее. В калифорнийском университете институт Ирвайна по исследованию ПО в первую очередь исследует архитектурные стили, языки описания архитектуры и динамические архитектуры.
Первым стандартом программной архитектуры является стандарт IEEE 1471: ANSI / IEEE 1471—2000: Рекомендации по описанию преимущественно программных систем. Он был принят в 2007 году, под названием ISO ISO / IEC 42010:2007.
Мнения относительно объема программных архитектур расходятся:
Нет четкого различия между архитектурой программного обеспечения и проектированием и разработкой требований (см. Связанные поля ниже). Все они являются частью «цепочки намерений» от высокоуровневых намерений до низкоуровневых деталей.
Архитектура программного обеспечения демонстрирует следующее:
Множество заинтересованных сторон: программные системы должны обслуживать множество заинтересованных сторон, таких как бизнес-менеджеры, владельцы, пользователи и операторы. У всех этих заинтересованных сторон есть свои опасения по поводу системы. Уравновешивание этих проблем и демонстрация того, что они решены, является частью проектирования системы. . Это означает, что архитектура предполагает работу с широким кругом проблем и заинтересованных сторон и носит междисциплинарный характер.
Разделение проблем : общепринятый способ уменьшения сложности для архитекторов - разделение проблем, лежащих в основе дизайна. Документация по архитектуре показывает, что все проблемы заинтересованных сторон решаются путем моделирования и описания архитектуры с разных точек зрения, связанных с различными проблемами заинтересованных сторон. Эти отдельные описания называются архитектурными видами (см., Например, модель архитектурного вида 4 + 1 ).
Ориентация на качество: классические подходы к проектированию программного обеспечения (например, структурированное программирование Джексона ) основывались на требуемой функциональности и потоке данных через систему, но текущее понимание : 26–28 состоит в том, что архитектура программной системы более близка связанных с его атрибутами качества, такими как отказоустойчивость , обратная совместимость , расширяемость , надежность , ремонтопригодность , доступность , безопасность, удобство использования и другие подобные возможности . Обеспокоенность заинтересованных сторон часто выражается в требованияхпо этим атрибутам качества, которые по-разному называются нефункциональными требованиями , дополнительными функциональными требованиями, поведенческими требованиями или требованиями атрибутов качества.
Повторяющиеся стили: подобно архитектуре здания, дисциплина архитектуры программного обеспечения разработала стандартные способы решения повторяющихся проблем. Эти «стандартные способы» называются разными именами на разных уровнях абстракции. Общие термины для повторяющихся решений - это архитектурный стиль, тактика, эталонная архитектура и архитектурный образец .
Концептуальная целостность: термин, введенный Фредом Бруксом в «Мифическом человеко-месяце» для обозначения идеи о том, что архитектура программной системы представляет собой общее видение того, что она должна делать и как она должна это делать. Это видение следует отделить от его реализации. Архитектор берет на себя роль «хранителя видения», следя за тем, чтобы дополнения к системе соответствовали архитектуре, тем самым сохраняя концептуальную целостность . [15] : 41–50
Когнитивные ограничения: наблюдение, впервые сделанное в 1967 году программистом Мелвином Конвеем, о том, что организации, проектирующие системы, вынуждены производить проекты, которые являются копиями коммуникационных структур этих организаций. Как и в случае с концептуальной целостностью, именно Фред Брукс представил ее более широкой аудитории, когда он процитировал статью и идею в своей элегантной классической книге «Мифический человеко-месяц» , назвав ее «законом Конвея».
Архитектура программного обеспечения - это «интеллектуально понятная» абстракция сложной системы. Эта абстракция дает ряд преимуществ:
Сравнение между проектированием программного обеспечения и (гражданской) архитектурой было впервые проведено в конце 1960-х , но термин «программная архитектура» не получил широкого распространения до 1990-х годов. В области компьютерных наук с самого начала возникали проблемы, связанные со сложностью. Ранее проблемы сложности решались разработчиками путем выбора правильных структур данных , разработки алгоритмов и применения концепции разделения проблем . Хотя термин «архитектура программного обеспечения» является относительно новым для отрасли, фундаментальные принципы этой области время от времени применялись при разработке программного обеспечения.пионеры с середины 1980-х гг. Ранние попытки зафиксировать и объяснить программную архитектуру системы были неточными и дезорганизованными, часто характеризовались набором прямоугольных диаграмм .
Архитектура программного обеспечения как концепция возникла в исследованиях Эдсгера Дейкстры в 1968 году и Дэвида Парнаса в начале 1970-х годов. Эти ученые подчеркнули, что структура программной системы имеет значение, а правильная структура имеет решающее значение. В течение 1990-х годов предпринимались согласованные усилия по определению и кодификации фундаментальных аспектов дисциплины, при этом исследовательская работа концентрировалась на архитектурных стилях ( шаблонах ), языках описания архитектуры , архитектурной документации и формальных методах .
Исследовательские институты сыграли заметную роль в развитии архитектуры программного обеспечения как дисциплины. Мэри Шоу и Дэвид Гарлан из Карнеги-Меллона написали книгу под названием « Архитектура программного обеспечения: перспективы новой дисциплины» в 1996 году, в которой продвигались концепции архитектуры программного обеспечения, такие как компоненты , соединители и стили. Университет Калифорнии, Ирвин Института в деятельности Software Research , в исследованиях архитектуры программного обеспечения направлена в первую очередь архитектурных стилей, языков описания архитектуры и динамических архитектур.
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. [28] Структуры для сравнения методов обсуждаются в таких структурах, как Отчет SARA и Обзоры архитектуры: практика и опыт .
Эволюция архитектуры - это процесс поддержки и адаптации существующей архитектуры программного обеспечения к изменениям требований и среды. Поскольку программная архитектура обеспечивает фундаментальную структуру программной системы, ее развитие и обслуживание обязательно повлияют на ее фундаментальную структуру. Таким образом, эволюция архитектуры связана с добавлением новых функций, а также поддержанием существующих функций и поведения системы.
Архитектура требует критически важных вспомогательных действий. Эти вспомогательные действия осуществляются на протяжении всего процесса базовой архитектуры программного обеспечения. Они включают в себя управление знаниями и коммуникацию, конструкторское обоснование и принятие решений, а также документацию.
Действия по поддержке архитектуры программного обеспечения выполняются во время основных операций по архитектуре программного обеспечения. Эти вспомогательные действия помогают архитектору программного обеспечения выполнять анализ, синтез, оценку и развитие. Например, архитектор должен собирать знания, принимать решения и документировать на этапе анализа.
Языки описания архитектуры (ADLS) используются для описания архитектуры программного обеспечения. Различными организациями было разработано несколько различных ADLS, в том числе AADL (стандарт SAE), Wright (разработан в университете Carnegie Mellon), Acme (разработан в университете Carnegie Mellon), xADL (разработан в UCI), Darwin (разработан в Imperial College в Лондоне), DAOP-ADL (разработан в Университете Малаги), а также ByADL (Университет L’Aquila, Италия). Общими элементами для всех этих языков являются понятия компонента, коннектора и конфигурации.
Архитектура ПО обычно содержит несколько видов, которые аналогичны различным типам чертежей в строительстве зданий. В онтологии, установленной ANSI / IEEE 1471—2000, виды являются экземплярами точки зрения, где точка зрения существует для описания архитектуры с точки зрения заданного множества заинтересованных лиц.
Примеры видов:
Архитектурный вид состоит из 2 компонентов:
Архитектурные виды можно поделить на 3 основных типа[10]:
Примеры модульных видов:
Примеры видов компонентов-и-коннекторов:
Примеры видов размещения:
Хотя было разработано несколько языков для описания архитектуры программного обеспечения, в настоящий момент нет согласия по поводу того, какой набор видов должен быть принят в качестве эталона. В качестве стандарта «для моделирования программных систем (и не только)» был создан язык UML.
Описание архитектуры программного обеспечения включает в себя принципы и методы моделирования и представления архитектур с использованием таких механизмов, как языки описания архитектуры, точки зрения на архитектуру и структуры архитектуры.
Язык описания архитектуры (ADL) - это любое средство выражения, используемое для описания архитектуры программного обеспечения ( ISO / IEC / IEEE 42010 ). Многие специальные ADL были разработаны с 1990-х годов, в том числе AADL (стандарт SAE), Wright (разработан Карнеги-Меллоном), Acme (разработан Карнеги-Меллоном), xADL (разработан UCI), Darwin (разработан Имперским колледжем Лондона ). , DAOP-ADL (разработан Университетом Малаги), SBC-ADL (разработан Национальным университетом Сунь Ят-Сена ) и ByADL (Университет Аквилы, Италия).
4 + 1 архитектурный вид .
Описания архитектуры программного обеспечения обычно организованы в представления , которые аналогичны различным типам чертежей, создаваемых в архитектуре здания . Каждое представление обращается к набору системных проблем, следуя соглашениям своей точки зрения , где точка зрения - это спецификация, которая описывает нотации, методы моделирования и анализа для использования в представлении, которое выражает рассматриваемую архитектуру с точки зрения данного набора заинтересованных сторон и их озабоченности ( ISO / IEC / IEEE 42010). Точка зрения определяет не только сформулированные проблемы (т. Е. Подлежащие рассмотрению), но и представление, используемые типы моделей, используемые соглашения и любые правила согласованности (соответствия) для сохранения согласованности взгляда с другими взглядами.
Структура архитектуры охватывает «соглашения, принципы и практики для описания архитектур, установленных в конкретной области приложения и / или сообществе заинтересованных сторон» ( ISO / IEC / IEEE 42010 ). Структура обычно реализуется в терминах одной или нескольких точек зрения или ADL.
Архитектурный шаблон является общим, многоразовые решением для часто встречающихся проблем в архитектуре программного обеспечения в данном контексте. Архитектурные шаблоны часто документируются как шаблоны проектирования программного обеспечения .
Следуя традиционной архитектуре зданий, «программный архитектурный стиль» - это особый метод строительства, характеризующийся особенностями, которые делают его заметным »( архитектурный стиль ).
Архитектурный стиль определяет: семейство систем с точки зрения структурной организации; словарь компонентов и соединителей с ограничениями на то, как их можно комбинировать.
Архитектурные стили - это многократно используемые «пакеты» проектных решений и ограничений, которые применяются к архитектуре для достижения выбранных желаемых качеств.
Существует множество признанных архитектурных образцов и стилей, среди которых:
Некоторые рассматривают архитектурные паттерны и архитектурные стили как одно и то же, [35] некоторые рассматривают стили как специализацию паттернов. Их объединяет то, что и шаблоны, и стили - это идиомы для использования архитекторами, они «обеспечивают общий язык» [35] или «словарь» [33], с помощью которого можно описывать классы систем.
Есть также опасения, что архитектура программного обеспечения приводит к слишком большому предварительному проектированию , особенно среди сторонников гибкой разработки программного обеспечения . Был разработан ряд методов, позволяющих уравновесить компромисс между предварительным проектированием и гибкостью [36], в том числе гибкий метод DSDM, который предусматривает фазу «Основы», во время которой закладывается «ровно достаточное количество» архитектурных основ. IEEE Software посвятила специальный выпуск взаимодействию гибкости и архитектуры.
Разрушение архитектуры программного обеспечения (или «распад») относится к разрыву, наблюдаемому между запланированной и фактической архитектурой программной системы, реализованной в ее реализации. [37] Разрушение архитектуры программного обеспечения происходит, когда решения по реализации либо не полностью соответствуют запланированной архитектуре, либо иным образом нарушают ограничения или принципы этой архитектуры.
В качестве примера рассмотрим строго многоуровневую систему, где каждый уровень может использовать только услуги, предоставляемые уровнем, находящимся непосредственно под ним. Любой компонент исходного кода, который не соблюдает это ограничение, представляет собой нарушение архитектуры. Если не исправить, такие нарушения могут превратить архитектуру в монолитный блок, что отрицательно скажется на понятности, ремонтопригодности и эволюционируемости.
Для борьбы с эрозией были предложены различные подходы. "Эти подходы, которые включают инструменты, методы и процессы, в первую очередь классифицируются на три общие категории, которые пытаются минимизировать, предотвратить и исправить эрозию архитектуры. В рамках этих широких категорий каждый подход далее разбивается, отражая стратегии высокого уровня, принятые для борьба с эрозией. Это процессно-ориентированные методы согласования архитектуры, управление развитием архитектуры, обеспечение соблюдения дизайна архитектуры, связь архитектуры с реализацией, самоадаптация и восстановление архитектуры, состоящие из восстановления, обнаружения и согласования ». [38]
Есть два основных метода обнаружения архитектурных нарушений: модели отражения и предметно-ориентированные языки. Методы модели рефлексии (RM) сравнивают высокоуровневую модель, предоставленную архитекторами системы, с реализацией исходного кода. Существуют также предметно-ориентированные языки с упором на определение и проверку архитектурных ограничений.
Восстановление архитектуры программного обеспечения (или реконструкция, или обратный инжиниринг ) включает в себя методы, приемы и процессы для раскрытия архитектуры программной системы на основе доступной информации, включая ее реализацию и документацию. Восстановление архитектуры часто необходимо для принятия обоснованных решений перед лицом устаревшей документации и эрозии архитектуры : решения о внедрении и обслуживании расходятся с предполагаемой архитектурой. [39] Существуют практики восстановления архитектуры программного обеспечения в виде статического программного анализа . Это часть предметов, охватываемых практикой интеллектуального программного обеспечения .
Для удовлетворения проектируемой системы различным атрибутам качества применяются различные архитектурные шаблоны (паттерны). Каждый шаблон имеет свои задачи и свои недостатки.
Примеры архитектурных шаблонов:
Однако, концепция MVC имеет и свои недостатки. В частности, из-за усложнения взаимодействия падает скорость работы системы.
Существуют следующие фреймворки, относящихся к области архитектуры ПО:
Такие примеры архитектур как фреймворк Захмана (Zachman Framework), DODAF и TOGAF относятся к области архитектуры предприятия (enterprise architectures).
Архитектура ПО является реализацией нефункциональных требований к системе, в то время как проектирование ПО является реализацией функциональных требований[источник не указан 149 дней].
Архитектура ПО, которую также можно представить себе в виде разработки стратегии — это деятельность, связанная с определением глобальных ограничений, накладываемых на проектирование системы, такие как выбор парадигмы программирования, архитектурных стилей, стандарты разработки ПО, основанные на использовании компонентов, принципы проектирования и ограничения, накладываемые государственным законодательством. Детальное проектирование, то есть разработка тактики — это деятельность, связанная с определением локальных ограничений проекта, такие как шаблоны проектирования, архитектурные модели, идиомы программирования и рефакторинга. Согласно «гипотезе напряжения/окрестности» (Intension/Locality Hyphotysis), различие между архитектурным и детальным проектированием определяется критерием окрестности (Locality Criteria), согласно которому утверждение, что дизайн ПО не является локальным (а является архитектурным) истинно тогда и только тогда, когда программа, которая удовлетворяет этому критерию может быть расширена в программу, которая не удовлетворяет ему. Например, стиль приложения клиент-сервер является архитектурным стилем (стратегическим дизайном), потому что программа, которая построена на этом принципе, может быть расширена в программу, которая не является клиент-сервером, например, путем добавления peer-to-peer узлов.
Архитектура является проектированием (дизайном), но не всякий дизайн является архитектурным дизайном. На практике, архитектор определяет грань между архитектурой программного обеспечения (архитектурным дизайном) и детальным дизайном (неархитектурным проектированием). Не существует правил или инструкций, как сделать это, которые подходят для любого случая.
Архитектура - это дизайн, но не весь дизайн архитектурен. На практике архитектор - это тот, кто проводит грань между архитектурой программного обеспечения (архитектурный проект) и детальным проектированием (неархитектурное проектирование). Не существует правил или руководящих принципов, подходящих для всех случаев, хотя были попытки формализовать различие. В соответствии с интенсионала / Местностью Гипотезы , ] различие между архитектурным и детальным проектированием определяется местность Критерий , [40] , согласно которому утверждение о разработке программного обеспечения не является локальным (архитектурным) , если и только если программа , которая удовлетворяет его, может быть расширен в программу, которая этого не делает. Например,Стиль клиент-сервер является архитектурным (стратегическим), потому что программа, построенная на этом принципе, может быть расширена до программы, не являющейся клиент-серверной, например, путем добавления одноранговых узлов.
Разработка требований и архитектура программного обеспечения могут рассматриваться как взаимодополняющие подходы: в то время как архитектура программного обеспечения нацелена на « пространство решений » или «как», разработка требований обращается к « пространству проблем » или «что». Требование к инженерному предполагает выявление , согласование , спецификацию , проверки , документацию и управление по требованиям . И разработка требований, и архитектура программного обеспечения вращаются вокруг интересов, потребностей и желаний заинтересованных сторон .
Существует значительное совпадение между разработкой требований и архитектурой программного обеспечения, о чем свидетельствует, например, исследование пяти методов архитектуры промышленного программного обеспечения, в котором делается вывод о том, что «входные данные (цели, ограничения и т. Д.) Обычно плохо определены и только обнаруживаются или становятся лучше. понимается, когда архитектура начинает проявляться » и что, хотя « большинство архитектурных проблем выражаются в виде требований к системе, они также могут включать обязательные проектные решения » . Короче говоря, требуемое поведение влияет на архитектуру решения, которая, в свою очередь, может вводить новые требования. [42] Такие подходы, как модель Твин Пикс [ нацелены на использование синергетического связь между требованиями и архитектурой.
Компьютерная архитектура
Архитектура компьютера нацелена на внутреннюю структуру компьютерной системы с точки зрения взаимодействующих аппаратных компонентов, таких как ЦП или процессор, шина и память .
Системная архитектура
Термин « системная архитектура » первоначально применялся к архитектуре систем , состоящей как из аппаратного, так и программного обеспечения . Основная проблема, которую решает системная архитектура, - это интеграция программного и аппаратного обеспечения в законченное, правильно работающее устройство. В другом общем - гораздо более широком - значении этот термин применяется к архитектуре любой сложной системы, которая может иметь техническую, социотехническую или социальную природу.
Архитектура предприятия
Цель архитектуры предприятия - «преобразовать бизнес-видение и стратегию в эффективное предприятие». Структуры архитектуры предприятия , такие как TOGAF и Zachman Framework , обычно различают разные уровни архитектуры предприятия. Хотя терминология различается от структуры к структуре, многие из них включают, по крайней мере, различие между бизнес- уровнем , прикладным (или информационным ) уровнем и технологическим уровнем . Архитектура предприятия направлена, среди прочего, на согласование между этими уровнями, обычно по принципу «сверху вниз».
.1 Многоуровневый шаблон
2. Клиент-серверный шаблон
3. Ведущий-ведомый
4. Каналы и фильтры
5. Шаблон посредника
6. Одноранговый шаблон
7. Шина событий
8. Модель-представление-контроллер
9. Доска
10. Интерпретатор
Данный шаблон используется для структурирования программ, которые можно разложить на группы неких подзадач, находящихся на определенных уровнях абстракции. Каждый слой предоставляет службы для следующего, более высокого слоя.
Чаще всего в общих информационных системах встречаются следующие 4 слоя:
· Слой представления (также известен как слой пользовательского интерфейса)
· Слой приложения (также известен как слой сервиса)
· Слой бизнес-логики (также известен как уровень предметной области)
· Слой доступа к данным (также известен как уровень хранения данных)
· Общие десктопные приложения.
· Веб-приложения e-commerce.
Многоуровневый шаблон
Данный шаблон состоит из двух частей: сервера и множества клиентов. Серверный компонент предоставляет службы клиентским компонентам. Клиенты запрашивают услуги у сервера, а он, в свою очередь, оказывает эти самые услуги клиентам. Более того, сервер продолжает «подслушивать» клиентские запросы.
· Онлайн приложения (электронная почта, совместный доступ к документам, банковские услуги).
Шаблон «Клиент-сервер»
В этом шаблоне также задействованы два участника — ведущий и ведомые. Ведущий компонент распределяет задачи среди идентичных ведомых компонентов и вычисляет итоговый результат на основании результатов, полученных от своих «подчиненных».
· В репликации баз данных. Там главная БД считается авторитетным источником, а подчиненные базы с ней синхронизируются.
· Периферийные устройства, подключенные к шине в компьютере (ведущие и ведомые устройства).
Шаблон «Ведущий-ведомый»
Этот шаблон подходит для систем, которые производят и обрабатывают потоки данных. Каждый этап обработки происходит внутри некоего компонента фильтра. Данные для обработки передаются через каналы. Эти каналы можно использовать для буферизации или синхронизации данных.
· Компиляторы. Последовательные фильтры выполняют лексический, синтаксический, семантический анализ и создание кода.
· Рабочие процессы в биоинформатике.
Шаблон «Каналы и фильтры»
Данный шаблон нужен для структуризации распределенных систем с несвязными компонентами. Эти компоненты могут взаимодействовать друг с другом через удаленный вызов службы. Компонент посредник отвечает за координацию взаимодействия компонентов.
Сервер размещает свои возможности (службы и характеристики) у посредника (брокера). Клиент запрашивает услугу у брокера. Затем брокер перенаправляет клиента к подходящей службе из своего реестра.
· Брокеры сообщений по типу Apache ActiveMQ, Apache Kafka, RabbitMQ и JBoss Messaging.
Шаблон «Посредник»
В данном шаблоне существуют отдельные компоненты, так называемые пиры. Пиры могут выступать в роли как клиента, запрашивающего услуги от других равноправных участников (пиров), так и сервера, предоставляющего услуги другим пирам. Пир может быть клиентом или сервером, или всем сразу, а также способен со временем динамически изменять свою роль.
· Файлообменные сети (Gnutella и G2)
· Мультимедийные протоколы (P2PTV и PDTP)
· Проприетарные мультимедийные приложения (как тот же Spotify).
Одноранговый шаблон
Этот шаблон, в основном, взаимодействует с событиями и состоит из 4 главных компонентов: источник события, прослушиватель события, канал и шина событий. Источники размещают сообщения для определенных каналов на шине событий. Прослушиватели подписываются на определенные каналы. Прослушиватели получают уведомления о появлении сообщений, размещенных на каналах из их подписки.
· Разработки на Android
· Сервисы уведомлений
Шаблон «Шина событий»
Этот шаблон также известен как MVC-шаблон. Он разделяет интерактивные прикладные программы на 3 части:
1. модель — содержит ключевые данные и функционал;
2. представление — показывает информацию пользователю (можно задавать более одного представления);
3. контроллер — занимается обработкой данных от пользователя.
Это делается с целью разграничения внутреннего представления информации от способов ее представления и принятия от пользователя. Данная схема изолирует компоненты и позволяет эффективно реализовать повторное использование кода.
· Архитектура WWW-приложений, написанных на основных языках программирования.
· Веб-фреймворки (например, Django и Rails)
Шаблон «Модель-представление-контроллер»
Такой шаблон подходит для проблем, для которых отсутствуют четкие детерминированные решения. Шаблон «Доска» состоит из 3 главных компонентов:
· доска — это структурированная глобальная память, содержащая объекты из пространства возможных решений;
· источник знания — специализированные модули со своим собственным представлением;
· компоненты управления — выбирает, настраивает и исполняет модули.
Все компоненты имеют доступ к доске. Компоненты могут производить новые объекты данных, которые добавляются к доске. Компоненты ищут на доске конкретные виды данных. Одним из способов поиска является сопоставление шаблонов с существующим источником знаний.
Шаблон «Доска»
Он подходит для разработки компонента, который должен интерпретировать программы, написанные на специальном языке программирования. В основном, там расписано, как вычислять строки (иначе говоря: «предложения» или «выражения»), написанные на каком-то определенном языке программирования. Суть в том, чтобы присвоить класс каждому символу языка.
· языки запросов к базе данных (SQL);
· языки, которые используются для описания протоколов передачи данных.
Шаблон «Интерпретатор»
Ниже приводятся плюсы и минусы каждого из архитектурных шаблонов.
Сравнение архитектурных шаблонов
Плюсы:
Минусы:
Плюсы:
Минусы:
Плюсы:
Минусы:
Плюсы:
Минусы:
Плюсы:
Минусы:
Плюсы:
Минусы:
Плюсы:
Минусы:
Плюсы:
Минусы:
Плюсы:
Минусы:
Плюсы:
Минусы:
В программной инженерии многоуровневая архитектура или многослойная архитектура — клиент-серверная архитектура, в которой разделяются функции представления, обработки и хранения данных. Наиболее распространенной разновидностью многоуровневой архитектуры является трехуровневая архитектура.
N-уровневая архитектура приложения предоставляет модель, по которой разработчики могут создавать гибкие и повторно-используемые приложения. Разделяя приложение на уровни абстракции, разработчики приобретают возможность внесения изменений в какой-то определенный слой, вместо того, чтобы перерабатывать все приложение целиком. Трехуровневая архитектура обычно состоит из уровня представления, уровня бизнес-логики и уровня хранения данных.
Хотя понятия слоя и уровня зачастую используются как взаимозаменяемые, многие сходятся во мнении, что между ними все-таки есть различие. Различие заключается в том, что слой — это механизм логического структурирования компонентов, из которых состоит программное решение, в то время как уровень — это механизм физического структурирования инфраструктуры системы. Трехслойное решение легко может быть развернуто на единственном уровне, таком как персональная рабочая станция.
Архитектурный шаблон «Слои» (англ. Layers) помогает структурировать приложения разложением на группы подзадач, находящихся на определенных уровнях абстракции.
В логически разделенных на слои архитектурах информационных систем наиболее часто встречаются следующие четыре слоя:
Книга Предметно-ориентированное проектирование (DDD) описывает некоторые общепринятые способы применения обозначенных четырех слоев, хотя фокус в ней смещен в сторону слоя предметной области.
Некоторые также выделяют в отдельный слой бизнес инфраструктуры (BI) то, что расположено между слоем (слоями) бизнес-логики и слоем (слоями) инфраструктуры. Иногда этот слой именуется «нижнеуровневым слоем бизнес-логики» или «слоем бизнес-сервисов». Этот слой является очень обобщенным и может быть использован на нескольких уровнях приложения (такого как Конвертер валют).
Слой инфраструктуры может быть подразделен на уровни: высокоуровневые и низкоуровневые технические сервисы. Разработчики зачастую концентрируют свое внимание на возможностях доступа к данным слоя инфраструктуры и вследствие в разговоре упоминают о нем только как о слое доступа к данным (вместо более общего «слоя инфраструктуры» или «слоя технических сервисов»). Другими словами, об иных разновидностях технических сервисов не всегда задумываются как о части определенного слоя.
Каждый слой зависит только от нижележащего слоя и может существовать без вышерасположенных слоев. Еще одна распространенная точка зрения заключается в том, что слои не всегда строго зависят от слоя расположенного непосредственно под ними. Например, в нестрогой многослойной системе (англ. a relaxed layered system) какой-то слой может зависеть от всех расположенных ниже слоев
Есть много распространенных способов разработки программных модулей и их связей, в том числе:
«Клиент — сервер» (англ. client–server) — вычислительная или сетевая архитектура, в которой задания или сетевая нагрузка распределены между поставщиками услуг, называемыми серверами, и заказчиками услуг, называемыми клиентами. Фактически клиент и сервер — это программное обеспечение. Обычно эти программы расположены на разных вычислительных машинах и взаимодействуют между собой через вычислительную сеть посредством сетевых протоколов, но они могут быть расположены также и на одной машине. Программы-серверы ожидают от клиентских программ запросы и предоставляют им свои ресурсы в виде данных (например, загрузка файлов посредством HTTP, FTP, BitTorrent, потоковое мультимедиа или работа с базами данных) или в виде сервисных функций (например, работа с электронной почтой, общение посредством систем мгновенного обмена сообщениями или просмотр web-страниц во всемирной паутине). Поскольку одна программа-сервер может выполнять запросы от множества программ-клиентов, ее размещают на специально выделенной вычислительной машине, настроенной особым образом, как правило, совместно с другими программами-серверами, поэтому производительность этой машины должна быть высокой. Из-за особой роли такой машины в сети, специфики ее оборудования и программного обеспечения, ее также называют сервером, а машины, выполняющие клиентские программы, соответственно, клиентами.
Характеристика клиент-сервер описывает отношения взаимодействующих программ в приложении. Серверный компонент предоставляет функцию или услугу одному или нескольким клиентам, которые инициируют запросы на такие услуги. Серверы классифицируются по предоставляемым ими услугам. Например, веб-сервер обслуживает веб-страницы, а файловый сервер обслуживает компьютерные файлы. Общий ресурс может быть любой из программного обеспечения и электронных компонентов компьютера — сервера, от программ и данных в процессорах и запоминающих устройств. Совместное использование ресурсов сервера представляет собой услугу.
Является ли компьютер клиентом, сервером или и тем, и другим, определяется характером приложения, которому требуются сервисные функции. Например, на одном компьютере могут одновременно работать веб-серверы и программное обеспечение файлового сервера, чтобы обслуживать разные данные для клиентов, отправляющих различные типы запросов. Клиентское программное обеспечение также может взаимодействовать с серверным программным обеспечением на том же компьютере. Связь между серверами, например, для синхронизации данных, иногда называется межсерверной.
Вообще говоря, служба — это абстракция компьютерных ресурсов, и клиенту не нужно беспокоиться о том, как сервер работает при выполнении запроса и доставке ответа. Клиенту нужно только понять ответ, основанный на известном протоколе приложения, то есть содержание и форматирование данных для запрашиваемой услуги.
Клиенты и серверы обмениваются сообщениями в шаблоне запрос-ответ. Клиент отправляет запрос, а сервер возвращает ответ. Этот обмен сообщениями является примером межпроцессного взаимодействия. Для взаимодействия компьютеры должны иметь общий язык, и они должны следовать правилам, чтобы и клиент, и сервер знали, чего ожидать. Язык и правила общения определены в протоколе связи. Все протоколы клиент-серверной модели работают на уровне приложений. Протокол прикладного уровня определяет основные шаблоны диалога. Чтобы еще больше формализовать обмен данными, сервер может реализовать интерфейс прикладного программирования (API). API — это уровень абстракции для доступа к сервису. Ограничивая связь определенным форматом контента, он облегчает синтаксический анализ. Абстрагируя доступ, он облегчает межплатформенный обмен данными.
Сервер может получать запросы от множества различных клиентов за короткий период времени. Компьютер может выполнять только ограниченное количество задач в любой момент и полагается на систему планирования для определения приоритетов входящих запросов от клиентов для их удовлетворения. Чтобы предотвратить злоупотребления и максимизировать доступность серверное программное обеспечение может ограничивать доступность для клиентов. Атаки типа «отказ в обслуживании» используют обязанности сервера обрабатывать запросы, такие атаки действуют путем перегрузки сервера чрезмерной частотой запросов. Шифрование следует применять, если между клиентом и сервером должна передаваться конфиденциальная информация.
В дополнение к клиент-серверной модели распределенные вычислительные приложения часто используют peer-to-peer архитектуру.
Клиент-сервер часто проектируется как централизованная система, которая обслуживает множество клиентов. Таким образом, требования к мощности, памяти и объему хранилища сервера должны масштабироваться с ожидаемой нагрузкой. Системы балансировки нагрузки и отказоустойчивости часто используются для масштабирования сервера за пределами одной физической машины. В одноранговой сети два или более компьютера объединяют свои ресурсы и взаимодействуют в децентрализованной системе. Одноранговые узлы — это равноправные или эквипотентные узлы в неиерархической сети. В отличие от клиентов в архитектуре клиент-сервер или клиент-очередь-клиент, одноранговые узлы взаимодействуют друг с другом напрямую. В одноранговой сети алгоритм в одноранговом коммуникационном протоколе балансирует нагрузку, и даже одноранговые узлы с небольшим количеством ресурсов могут помочь разделить нагрузку. Если узел становится недоступным, его общие ресурсы остаются доступными до тех пор, пока другие одноранговые узлы предлагают их. В идеале узлу не нужно достигать высокой доступности, поскольку другие узлы компенсируют любое время простоя ресурсов. По мере изменения доступности и пропускной способности одноранговых узлов протокол перенаправляет запросы. Как клиент-сервер, так и ведущий-ведомый рассматриваются как подкатегории распределенных одноранговых систем.
Многоуровневая архитектура «клиент — сервер» — разновидность архитектуры «клиент — сервер», в которой функция обработки данных вынесена на несколько отдельных серверов. Это позволяет разделить функции хранения, обработки и представления данных для более эффективного использования возможностей серверов и клиентов.
Частные случаи многоуровневой архитектуры:
Сеть с выделенным сервером (англ. client/server network) — это локальная вычислительная сеть (LAN), в которой сетевые устройства централизованы и управляются одним или несколькими серверами. Индивидуальные рабочие станции или клиенты (такие, как ПК) должны обращаться к ресурсам сети через сервер(а).
Трехуровневая архитектура — это широко применяемая архитектура программного обеспечения в которой приложения разделены на три логических и физических уровня: уровень представления (пользовательский интерфейс), уровень приложения, на котором осуществляется обработка данных, и уровень данных, предназначенный для хранения и управления данными, относящимися к приложению.
Основное преимущество трехуровневой архитектуры заключается в том, что поскольку каждый уровень имеет собственную инфраструктуру, разработкой каждого уровня может заниматься отдельная команда разработчиков. Кроме того, каждый уровень можно обновлять и масштабировать по мере необходимости, не затрагивая другие уровни.
На протяжении десятилетий трехуровневая архитектура оставалась самой распространенной архитектурой для клиент-серверных приложений. Сегодня большинство трехуровневых архитектур подлежат модернизации с использованием облачных технологий, таких как контейнеры и микросервисы, а также требуют миграции в облако.По сравнению с двухзвенной клиент-серверной архитектурой или файл-серверной архитектурой трехуровневая архитектура обеспечивает, как правило, бо́льшую масштабируемость (за счет горизонтальной масштабируемости сервера приложений и мультиплексирования соединений), бо́льшую конфигурируемость (за счет изолированности уровней друг от друга). Реализация приложений, доступных из веб-браузера или из тонкого клиента, как правило, подразумевает развертывание программного комплекса в трехуровневой архитектуре. При этом обычно разработка трехзвенных программных комплексов сложнее, чем для двухзвенных, также наличие дополнительного связующего программного обеспечения может налагать дополнительные издержки в администрировании таких комплексов.
На уровне представления обеспечивается взаимодействие с пользователем приложения — это пользовательский интерфейс и уровень обмена данными. Его основное предназначение состоит в отображении информации и получении информации от пользователя. Этот уровень может работать в веб-браузере или как графический пользовательский интерфейс компьютерного или мобильного приложения. Уровни представления веб-приложений обычно разрабатываются с помощью HTML, CSS и JavaScript. Компьютерные и мобильные приложения могут быть написаны на любом языке в зависимости от платформы.
Уровень приложения, также известный как логический или промежуточный уровень, является центральным звеном приложения. На этом уровне обрабатывается информация, собранная на уровне представления — иногда с учетом другой информации из уровня данных — с помощью бизнес-логики, которая представляет собой набор бизнес-правил. Кроме того, уровень приложения может добавлять, изменять и удалять данные, расположенные на уровне данных.
Как правило, уровень приложения разрабатывается с помощью Python, Java, Perl, PHP или Ruby и взаимодействует с уровнем данных посредством вызовов API.
Уровень данных, который также называется уровнем базы данных, уровнем доступа к данным или базовым уровнем, предназначен для хранения и управления информацией, обработанной приложением. Его роль может выполнять реляционная система управления базами данных, такая как PostgreSQL, MySQL, MariaDB, Oracle, DB2, Informix или Microsoft SQL Server, либо сервер базы данных NoSQL, такой как Cassandra, CouchDB или MongoDB.
В трехуровневом приложении обмен данными осуществляется только через уровень приложения. Уровень представления и уровень данных не могут взаимодействовать друг с другом напрямую.
В контексте трехуровневой архитектуры термины уровень (tier) и слой (layer) часто используются как взаимозаменяемые, однако это не совсем справедливо.
Между ними следует делать различие. «Слой» разделяет части программы по функциональному признаку, а «уровни» не только имеют разный функционал, но и работают в независимой от других уровней инфраструктуре. Например, приложение Контакты на вашем телефоне представляет собой трехслойное приложение, но вместе с тем оно является одноуровневым, поскольку все три слоя работают на телефоне.
Эта разница имеет важное значение, поскольку слои не позволяют получить те преимущества, которые дает разделение по уровням.
Итак, главным преимуществом трехуровневой архитектуры является логическое и физическое разделение функциональных возможностей. Каждый уровень можно запустить в отдельной операционной системе и серверной платформе (веб-сервер, сервер приложений, сервер базы данных), наилучшим образом соответствующей его функциональным требованиям. Поскольку каждый уровень выполняется по крайней мере на одном выделенном аппаратном или виртуальном сервере, уровни можно настраивать и оптимизировать независимо друг от друга.
Другие преимущества (по сравнению с одноуровневой и двухуровневой архитектурой):
В случае веб-разработки уровни называются по-другому, но выполняют аналогичные функции:
Несмотря на доминирующее положение трехуровневой архитектуры, в своей работе вы можете встретиться с другими вариантами многоуровневых архитектур приложений.
Двухуровневая архитектура — это изначальный вариант клиент-серверной архитектуры, состоящей из слоя представления и слоя данных; бизнес-логика может находиться в слое представления и/или в слое данных. В случае двухуровневой архитектуры слой представления, а следовательно и конечный пользователь, обладают прямым доступом к слою данных и возможности бизнес-логики часто ограничивается. В качестве примера двухуровневого приложения можно привести простое приложение для управления контактами, в котором пользователи вводят и извлекают контактную информацию.
В общем случае N-уровневая архитектура, также называемая многоуровневой архитектурой, представляет собой любую архитектуру приложений, имеющую больше одного уровня. Однако приложения более чем с тремя уровнями встречаются крайне редко, поскольку дополнительные уровни не дают существенных преимуществ и могут сделать приложение более медленным, сложным в управлении и дорогим в обслуживании. Таким образом, n-уровневая архитектура и многоуровневая архитектура обычно являются синонимами трехуровневой архитектуры.
Исследование, описанное в статье про архитектура программного обеспечения, подчеркивает ее значимость в современном мире. Надеюсь, что теперь ты понял что такое архитектура программного обеспечения и для чего все это нужно, а если не понял, или есть замечания, то не стесняйся, пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Разработка программного обеспечения и информационных систем
Ответы на вопросы для самопроверки пишите в комментариях, мы проверим, или же задавайте свой вопрос по данной теме.
Комментарии
Оставить комментарий
Разработка программного обеспечения и информационных систем
Термины: Разработка программного обеспечения и информационных систем