Архитектура программного обеспечения кратко
Обновлено: 02.07.2024
Архитектура программного обеспечения (англ. software architecture ) — это структура программы или вычислительной системы, которая включает программные компоненты, видимые снаружи свойства этих компонентов, а также отношения между ними. Этот термин также относится к документированию архитектуры программного обеспечения. Документирование архитектуры ПО упрощает процесс коммуникации между заинтересованными лицами (англ. stakeholders ), позволяет зафиксировать принятые на ранних этапах проектирования решения о высокоуровневом дизайне системы и позволяет использовать компоненты этого дизайна и шаблоны повторно в других проектах.
Содержание
Обзор
История
Начало архитектуре программного обеспечения как концепции было положено в научно-исследовательской работе Эдсгера Дейкстры в 1968 году и Дэвида Парнаса в начале 1970-х. Эти ученые подчеркнули, что структура системы ПО имеет важное значение, и что построение правильной структуры — критически важно. Популярность изучения этой области возросла с начала 1990-х годов вместе с научно-исследовательской работой по исследованию архитектурных стилей (шаблонов), языков описания архитектуры, документирования архитектуры, и формальных методов.
Первым стандартом программной архитектуры является стандарт IEEE 1471: ANSI / IEEE 1471—2000: Рекомендации по описанию преимущественно программных систем. Он был принят в 2007 году, под названием ISO ISO / IEC 42010:2007.
Темы по программной архитектуре
Языки описания архитектуры
Языки описания архитектуры (ADLS) используются для описания архитектуры программного обеспечения. Различными организациями было разработано несколько различных ADLS, в том числе AADL (стандарт SAE), Wright (разработан в университете Carnegie Mellon), Acme (разработан в университете Carnegie Mellon), xADL (разработан в UCI), Darwin (разработан в Imperial College в Лондоне), DAOP-ADL (разработан в Университете Малаги), а также ByADL (Университет L’Aquila, Италия). Общими элементами для всех этих языков являются понятия компонента, коннектора и конфигурации.
Виды (views)
Архитектура ПО обычно содержит несколько видов, которые аналогичны различным типам чертежей в строительстве зданий. В онтологии, установленной ANSI / IEEE 1471—2000, виды являются экземплярами точки зрения, где точка зрения существует для описания архитектуры с точки зрения заданного множества заинтересованных лиц.
- Функциональный/логический вид
- Вид код/модуль
- Вид разработки (development)/структурный
- Вид параллельности выполнения/процесс/поток
- Физический вид/вид развертывания
- Вид с точки зрения действий пользователя
- Вид с точки зрения данных
Базовые фреймворки для архитектуры ПО (software architecture frameworks)
Существуют следующие фреймворки, относящихся к области архитектуры ПО:
- 4+1
- RM-ODP (Reference Model of Open Distributed Processing)
- Service-Oriented Modeling Framework (SOMF)
Такие примеры архитектур как фреймворк Захмана (Zachman Framework), DODAF и TOGAF относятся к области архитектуры предприятия (enterprise architectures).
Отличие архитектуры ПО от детального проектирования ПО
Архитектура ПО является реализацией нефункциональных требований к системе, в то время как проектирование ПО является реализацией функциональных требований.
Архитектура является проектированием (дизайном), но не всякий дизайн является архитектурным дизайном. На практике, архитектор определяет грань между архитектурой программного обеспечения (архитектурным дизайном) и детальным дизайном (неархитектурным проектированием). Не существует правил или инструкций, как сделать это, которые подходят для любого случая.
Примеры архитектурных стилей и моделей
Есть много распространенных способов разработки программных модулей и их связей, в том числе:
- Blackboard
- Клиент-серверная модель (client-server)
- Архитектуры, построенные вокруг базы данных (database-centric architecture)
- Распределенные вычисления (distributed computing)
- Событийная архитектура (event-driven architecture)
- Front end and back end
- Неявные вызовы (implicit invocations)
- Монолитное приложение (monolithic application)
- Peer-to-peer
- Пайпы и фильтры (pipes and filters)
- Plugin
- Representational State Transfer
- Rule evaluation
- Поиск-ориентированная архитектура
- Сервис-ориентированная архитектура
- Shared nothing architecture
- Software componentry
- Space based architecture
- Структурированная
- Трех-уровневая
Примечания
Ссылки
- Добавить иллюстрации. статью.
- Найти и оформить в виде сносок ссылки на авторитетные источники, подтверждающие написанное.
Кент Бек • Гради Буч • Фред Брукс • Barry Boehm • Уорд Каннингем • Оле-Йохан Даль • Том Демарко • Эдсгер Вибе Дейкстра • Дональд Кнут • Мартин Фаулер • Чарльз Энтони Ричард Хоар • Watts Humphrey • Майкл Джексон • Ивар Якобсон • Craig Larman • James Martin • Мейер Бертран • Дэвид Парнас • Winston W. Royce • James Rumbaugh • Никлаус Вирт • Эдвард Йордан • Стив Макконнелл
Моделирование данных • Архитектура ПО • Функциональная спецификация • Язык моделирования • Парадигма • Методология • Процесс разработки • Качество • Обеспечение качества • Структурный анализ)
CMM • CMMI • Данных • Function model • IDEF • Информационная • Metamodeling • Object model • View model • UML
- Архитектура программного обеспечения
- Разработка программного обеспечения
Wikimedia Foundation . 2010 .
Полезное
Смотреть что такое "Архитектура программного обеспечения" в других словарях:
архитектура программного обеспечения — — [Л.Г.Суменко. Англо русский словарь по информационным технологиям. М.: ГП ЦНИИС, 2003.] Тематики информационные технологии в целом EN software architecture … Справочник технического переводчика
Инженерия программного обеспечения — Новый Airbus A 380 использует довольно много ПО, чтобы создать современную кабину в самолете. Метод инженерии программного обеспечения позволил создать программное обеспечение самолёта, описываемое миллионами строк … Википедия
Производитель программного обеспечения — Разработка программного обеспечения (англ. software engineering, software development) это род деятельности (профессия) и процесс, направленный на создание и поддержание работоспособности, качества и надежности программного обеспечения, используя … Википедия
Тестирование программного обеспечения — Разработка программного обеспечения Процесс разработки ПО Шаги процесса Анализ • Проектирование • Программирование • Докумен … Википедия
Сопровождение программного обеспечения — Разработка программного обеспечения Процесс разработки ПО Шаги процесса Анализ • Проектирование • Программирование • Докумен … Википедия
Проектирование программного обеспечения — Разработка программного обеспечения Процесс разработки ПО Шаги процесса Анализ • Проектирование • Программирование • … Википедия
Качество программного обеспечения — Разработка программного обеспечения Процесс разработки ПО Шаги процесса Анализ • Проектирование • Программирование • Докумен … Википедия
Внедрение программного обеспечения — Эта статья слишком короткая. Пожалуйста … Википедия
Спецификация программного обеспечения — Спецификация требований программного обеспечения (англ. Software Requirements Specification, SRS) законченное описание поведения программы, которую требуется разработать. Включает ряд пользовательских сценариев (англ. use… … Википедия
Аннотация: Рассматривается понятие архитектуры ПО, влияние архитектуры на свойства ПО, а также методы оценки архитектуры. Рассказывается об основных элементах унифицированного языка моделирования UML.
Анализ области решений
Допустим, мы разобрались в предметной области , поняли, что требуется от будущей программной системы, даже зафиксировали настолько полно, насколько смогли, требования и пожелания всех заинтересованных лиц ко всем аспектам качества программы. Что делать дальше?
На этом этапе (а точнее, гораздо раньше, обычно еще в ходе анализа предметной области ) исследуются возможные способы решения тех задач, которые поставлены в требованиях. Не всегда бывает нужно специальное изучение этого вопроса — чаще всего имеющийся опыт разработчиков сразу подсказывает, как можно решать поставленные задачи. Однако иногда, все-таки, возникает потребность сначала понять, как это можно сделать и, вообще, возможно ли это сделать и при каких ограничениях.
Таким образом, явно или неявно, проводится анализ области решений. Целью этой деятельности является понимание, можно ли вообще решить стоящие перед разрабатываемой системой задачи, при каких условиях и ограничениях это можно сделать, как они решаются, если решение есть, а если нет — нельзя ли придумать способ его найти или получить хотя бы приблизительное решение, и т.п. Обычно задача хорошо исследована в рамках какой-либо области человеческих знаний, но иногда приходится потратить некоторые усилия на выработку собственных решений. Кроме того, решений обычно несколько и они различаются по некоторым характеристикам, способным впоследствии сыграть важную роль в процессе развития и эксплуатации созданной на их основе программы. Поэтому важно взвесить их плюсы и минусы и определить, какие из них наиболее подходят в рамках данного проекта, или решить, что все они должны использоваться для обеспечения большей гибкости ПО .
Когда определены принципиальные способы решения всех поставленных задач (быть может, в каких-то ограничениях), основной проблемой становится способ организации программной системы, который позволил бы реализовать все эти решения и при этом удовлетворить требованиям, касающимся нефункциональных аспектов разрабатываемой программы. Искомый способ организации ПО в виде системы взаимодействующих компонентов называют архитектурой, а процесс ее создания — проектированием архитектуры ПО .
Архитектура программного обеспечения
Под архитектурой ПО понимают набор внутренних структур ПО , которые видны с различных точек зрения и состоят из компонентов , их связей и возможных взаимодействий между компонентами , а также доступных извне свойств этих компонентов [1].
Под компонентом в этом определении имеется в виду достаточно произвольный структурный элемент ПО , который можно выделить, определив интерфейс взаимодействия между этим компонентом и всем, что его окружает. Обычно при разработке ПО термин " компонент " (см. далее при обсуждении компонентных технологий ) имеет несколько другой, более узкий смысл — это единица развертывания, самая маленькая часть системы, которую можно включить или не включить в ее состав. Такой компонент также имеет определенный интерфейс и удовлетворяет некоторому набору правил, называемому компонентной моделью . Там, где возможны недоразумения, будет указано, в каком смысле употребляется этот термин. В этой лекции до обсуждения UML мы будем использовать преимущественно широкое понимание этого термина, а дальше — наоборот, узкое.
В определении архитектуры упоминается набор структур, а не одна структура. Это означает, что в качестве различных аспектов архитектуры, различных взглядов на нее выделяются различные структуры, соответствующие разным аспектам взаимодействия компонентов. Примеры таких аспектов — описание типов компонентов и типов статических связей между ними при помощи диаграмм классов , описание композиции компонентов при помощи структур ссылающихся друг на друга объектов, описание поведения компонентов при помощи моделирования их как набора взаимодействующих, передающих друг другу некоторые события, конечных автоматов.
Архитектура программной системы похожа на набор карт некоторой территории. Карты имеют разные масштабы, на них показаны разные элементы (административно-политическое деление , рельеф и тип местности — лес , степь, пустыня, болота и пр., экономическая деятельность и связи), но они объединяются тем, что все представленные на них сведения соотносятся с географическим положением. Точно так же архитектура ПО представляет собой набор структур или представлений , имеющих различные уровни абстракции и показывающих разные аспекты (структуру классов ПО , структуру развертывания, т.е. привязки компонентов ПО к физическим машинам, возможные сценарии взаимодействий компонентов и пр.), объединяемых сопоставлением всех представленных данных со структурными элементами ПО . При этом уровень абстракции данного представления является аналогом масштаба географической карты.
Рассмотрим в качестве примера программное обеспечение авиасимулятора для командной тренировки пилотов. Задачей такой системы в целом является контроль и выработка необходимых для безопасного управления самолетом навыков у команд летчиков. Кроме того, отрабатываются навыки поведения в особых ситуациях, связанных с авариями, частичной потерей управления самолетом, тяжелыми условиями полета, и т.д.
- Моделировать определенные условия полета и создавать некоторые события, к которым относятся следующие:
- Скоростной и высотный режим полета, запас горючего, их изменения со временем.
- Модель самолета и ее характеристики по управляемости, возможным режимам полета и скорости реакции на различные команды.
- Погода за бортом и ее изменения со временем.
- Рельеф и другие особенности местности в текущий момент, их изменения со временем.
- Исходный и конечный пункты полета, расстояние и основные характеристики рельефа между ними.
- Исправность или неисправность элементов системы контроля полета и управления самолетом, показатели системы мониторинга и их изменение со временем.
- Наличие пролетающих вблизи курса самолета других самолетов, их геометрические и скоростные характеристики.
- Чрезвычайные ситуации, например, террористы на борту, нарушение герметичности корпуса, внезапные заболевания и "смерть" отдельных членов экипажа.
При этом вся совокупность условий должна быть непротиворечивой, выглядеть и развиваться подобно реальным событиям. Некоторые условия, например, погода, должны изменяться достаточно медленно, другие события — происходить внезапно и приводить к связанным с ними последствиям (нарушение герметичности корпуса может сопровождаться поломками каких-то элементов системы мониторинга или "смертью" одного из пилотов). Если приборы показывают наличие грозы по курсу и они исправны, через некоторое время летчики должны увидеть грозу за бортом и она может начать оказывать влияние на условия полета.
Понятно, что одним из элементов симулятора служит система визуализации обстановки за бортом — она показывает пилотам "вид за окнами". Пилоты в ходе полета ориентируются по показателям огромного количества датчиков, представленных на приборной панели самолета. Вся их работа тоже должна симулироваться. Наличие и характеристики работы таких датчиков могут зависеть от симулируемой модели, но их расположение, форма и цвет служат слишком важными элементами выработки навыков управления самолетом, поэтому требуется поддерживать эти характеристики близкими к реальным. Представлять их только в виде изображений на некоторой панели неудобно, поскольку они должны располагаться и выглядеть максимально похоже на реальные прототипы. Значит, симулировать можно только небольшое семейство самолетов с практически одним и тем же набором приборов на приборной панели.
Балансировка нагрузки: равномерно распределяйте запросы по разным серверам для достижения баланса.
Высокая степень параллелизма: возможность обрабатывать одно и то же одновременно (решения: распределенные, кластерные, с балансировкой нагрузки)
Высокая доступность: система доступна.
![]()
Разработка архитектуры программного обеспечения прошла через процесс эволюции от монолитной архитектуры, вертикальной архитектуры, распределенной архитектуры до архитектуры мобильных вычислений, как показано на следующем рисунке:
1. Монолитная архитектура приложения
Когда трафик веб-сайта очень мал, требуется только одно приложение, и все функции развертываются вместе, чтобы уменьшить количество узлов развертывания и затраты. В настоящее время ключевым моментом является структура доступа к данным (ORM), используемая для упрощения рабочей нагрузки по добавлению, удалению, изменению и проверке.
- Преимущества архитектуры:
Структура проста, начальная стоимость разработки низкая, а цикл разработки короткий, подходит для небольших проектов (OA, CRM, ERP). - Недостатки архитектуры:
Все функции интегрированы в один проект
(1) Бизнес-код сильно связан, и его нелегко поддерживать.
(2) Высокая стоимость обслуживания, нелегко расширить
(3) Уровень параллелизма велик, и его трудно решить.
(4) Стек технологий ограничен и может быть разработан только на одном языке.
2. Вертикальная архитектура приложений
Когда количество посещений постепенно увеличивается, ускорение, вызванное добавлением одного приложения к машине, становится все меньше и меньше, и приложение делится на несколько несвязанных приложений для повышения эффективности. В настоящее время ключевым моментом является веб-фреймворк (MVC), используемый для ускорения разработки интерфейсных страниц.
- Преимущества архитектуры:
(1) Относительное разделение бизнес-кодов
(2) Затраты на обслуживание относительно легко увеличить (измените функцию, вы можете напрямую изменить проект и развернуть отдельно)
(3) Большой параллелизм относительно легко решить (создать кластер).
(4) Технологический стек может быть расширен (разные системы могут быть написаны на разных языках программирования). - Недостатки архитектуры:
Функции сосредоточены в одном проекте, что не способствует развитию, расширению и обслуживанию.
Между кодами существует избыточность данных и методов.
3. Распределенная сервисная архитектура
Когда появляется все больше и больше вертикальных приложений, взаимодействие между приложениями неизбежно.Основной бизнес выделяется как независимая услуга, и постепенно формируется стабильный сервисный центр, чтобы интерфейсные приложения могли быстрее реагировать на меняющиеся потребности рынка. В настоящее время для улучшения повторного использования и интеграции бизнеса Платформа распределенного обслуживания (RPC) - это ключ.
- Преимущества архитектуры:
(1) Бизнес-код полностью разделен и может быть универсальным.
(2) Стоимость обслуживания легко увеличить (изменить функцию, вы можете напрямую изменить проект и развернуть отдельно)
(3) Легко решить проблему большого количества параллелизма (создать кластер)
(4) Стек технологий полностью расширен (разные системы могут быть написаны на разных языках программирования). - Недостатки архитектуры:
не хватает структуры для унифицированного управления планированием ресурсов.
4. Архитектура мобильных вычислений
Когда появляется все больше и больше услуг, постепенно возникают такие проблемы, как оценка емкости и нерациональное использование небольших ресурсов службы. В настоящее время необходимо добавить диспетчерский центр для управления емкостью кластера в режиме реального времени на основе давления доступа для улучшения использования кластера. В настоящее время для повышения коэффициента использования машины Центр планирования ресурсов и управления (SOA) - это ключ.
- Преимущества архитектуры:
(1) Бизнес-код полностью разделен и может быть универсальным.
(2) Стоимость обслуживания легко увеличить (изменить функцию, вы можете напрямую изменить проект и развернуть отдельно)
(3) Легко решить проблему большого количества параллелизма (создать кластер)
(4) Стек технологий полностью расширен (разные системы могут быть написаны на разных языках программирования).
1. Монолитная архитектура приложения, также известная как централизованная архитектура.
![]()
2. Распределенная архитектура
![]()
3. Архитектура SOA
Эволюция вертикальной архитектуры Распределенная архитектура
4. Архитектура SOA:
Сервисно-ориентированная архитектура (SOA) - это компонентная модель, полное название: Сервис-ориентированная архитектура, которая разделяет различные функциональные единицы (называемые сервисами) приложения и связывает их через четко определенные интерфейсы и контракты между этими сервисами. вставать.
Интерфейс определяется нейтрально и не должен зависеть от аппаратной платформы, операционной системы и языка программирования, реализующего службу. Это позволяет сервисам, встроенным в различные системы, взаимодействовать унифицированным и универсальным образом.
Вы можете использовать даббо в качестве инструмента планирования (протокол RPC)
5. Микросервисная архитектура
Уровень системных служб полностью независим и извлекается как микросервисы один за другим.
Степень детализации извлечения более мала, следуя единому принципу, и данные могут передаваться между службами (обычно с использованием запросов на восстановление для вызова ресурсов).
Каждая служба использует отдельную базу данных, полностью независимую и несвязанную.
6. Процесс эволюции:
От архитектуры единого приложения (централизованная архитектура) -> распределенная архитектура -> архитектура SOA
Он все еще развивается, и звонки также могут выполняться между службами
То есть: микросервисная архитектура (сервисы тоже можно вызывать).
Функция 2: каждая служба использует отдельную базу данных, полностью независимую и несвязанную.
Интеллектуальная рекомендация
Говоря о супермапе ICLID для листовки (2) точка рисования, функциональные шаги функции изображения
После получения в последний раз мы сказали, что функции и приложения, которые я узнал позже, нет места, чтобы сказать, что каждый укажет Позвольте мне представить функции, которые я хочу сделат.
Tooltip + F2
Разработайте программу JAVA на ECLIPSE. Когда мы открываем класс JAVA, ECLIPSE откроет JDT JAVA EDITOR для отображения этого класса. Когда мы подведем мышь к определенному типу JAVA, появится подсказк.
![]()
Ali ECS (Linux Centos) устанавливает Центр регистрации NACOS
![]()
Python поднимается на 2011-2019 годы в Хэнане
![]()
Введение в управление состоянием Flink и механизм отказоустойчивости
Эта статья была опубликована на встрече Flink Meetup, состоявшейся в Пекине 11 августа. Рассказывает Ши Сяоган. В настоящее время он занимается исследованиями и разработками Blink в отделе больших дан.
Вам также может понравиться
2.28 Меч относится к предложению разбить массив на наименьшее число.
тема Введите массив положительных целых чисел, объедините все числа в массиве в одно число и выведите наименьшее из всех чисел, которые можно соединить вместе. Например, введите массив , а.
![]()
День 1-Java-imooc-4. Заявление об управлении процессом
![]()
Алгоритм взрывного заказа
Работа сортировки пузырьков выглядит следующим образом: 1. Сравните соседние элементы, если первое больше, чем второе больше, обменивайте два элемента позиций. 2. Та же работа вып.
Теория чисел Струна Скарлет не может быть такой милой
Значение темы: Найти набор символов как k k kДлина L L LСтрока, которая не удовлетворяет никого дольше, чем 1 1 1Количество последовательных палиндромных подстрок, которые могут указывать первые s s s.
![]()
Конвейер межпроцессного взаимодействия
Что такое межпроцессное взаимодействие? Буквальное значение - позволить двум процессам передавать информацию друг другу, а суть - позволить двум несвязанным процессам видеть один и тот же ресурс. Цель.
На старте мы использовали традиционную трёхзвенную архитектуру. Со временем значительно выросло число клиентов, появились новые услуги и партнёры, мы приняли решение усилить модульность нашей системы.
Типы архитектур ПО
Многоуровневая архитектура
![b_5bb33bb8b2ba4.jpg]()
О многоуровневой архитектуре написано бесчисленное количество книг и статей. И сложились разные мнения о ее достоинствах и недостатках.
Плюсы:
Недостатки:
В программировании есть присказка, что любую проблему можно решить добавлением еще одного уровня абстракции. Однако такой подход в конечном счете может привести к плохой организации кода и запутать разработчиков.Отсюда вытекает еще одна проблема — низкая скорость работы. Очень много информации начинает бесполезно проходить от слоя к слою, не используя бизнес-логику. Иногда эту проблему называют sinkhole anti-pattern — шаблон проектирования, когда количество бесполезных операций начинает преобладать над полезными.Поиск багов в многоуровневых системах также может быть затруднен. Прежде чем попасть в базу данных, информация проходит через все уровни (так как БД является конечным компонентом). Если по какой-то причине эта информация повреждается (или теряется по пути), то для поиска ошибки приходится анализировать каждый уровень по отдельности.
Хорошо подходит:
Когда мы в 1cloud начинали работу над внутренними системами нашего провайдера виртуальной инфраструктуры, то использовали именно этот тип архитектуры. На старте перед нами не стояла задача сделать IaaS-сервис, способный обработать трафик десятков или сотен тысяч пользователей. Мы решили оперативно выпустить продукт на рынок и начать нарабатывать клиентскую базу, а проблемы масштабирования решать по мере их поступления (и сейчас мы переводим все системы на микросервисную архитектуру, о которой далее).
Событийно-ориентированная архитектура
Достоинства архитектуры:
Так как приложения состоят из большого количества асинхронных модулей (у которых нет информации о реализации друг друга), их легко масштабировать. Такие системы собираются как конструктор — прописывать зависимости не нужно, достаточно реализовать новый модуль. Дополнительно асинхронная модель позволяет добиться высокой производительности приложений.
Недостатки:
Микроядерная архитектура
Этот тип архитектуры состоит из двух компонентов: ядра системы и плагинов. Плагины отвечают за бизнес-логику, а ядро руководит их загрузкой и выгрузкой.
![b_5bb33bb8ec62d.jpg]()
Достоинства архитектуры:
Легко портировать приложение из одной среды в другую, поскольку модифицировать нужно только микроядро. Разделение высокоуровневых политик и низкоуровневых механизмов упрощает поддержку системы и обеспечивает её расширяемость.
Недостатки:
Производительность приложения снижается, если подключать слишком много модулей. Однако бывает проблематично найти баланс между количеством плагинов и числом задач микроядра (обычно оно содержит лишь часто используемой код).Также сложно определить заранее (до начала разработки приложения) оптимальную степень дробления кода микроядра. А поменять подход позднее практически невозможно.
Хорошо подходит для:
Микросервисы
Достоинства:
Почему мы в 1cloud переходим на микросервисы
Читайте также:
