Архитектурные стили — Coursera Архитектура программного обеспечения Заметки к курсу

Итак, это вторые заметки в моей заметке о курсе Coursera Software Architecture Course Notes. Эта часть длиннее первой и рассказывает об архитектурных стилях. Я нахожу эту часть очень интересной, потому что она дает мне информацию о том, как мне создавать свое программное обеспечение.

А. Языковые системы

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

1. Абстрактные типы данных и объектно-ориентированный дизайн.

Если инженер-программист решит использовать ООП, это может привести к использованию этого типа архитектурного проектирования. Как работают класс и объект.

2. Основная программа и подпрограмма

Эти архитектурные стили ориентированы на функции. Они развиваются из парадигмы процедурного программирования. C является примером языка, который следует этой парадигме. Разбиваем систему на основную программу и подпрограммы.

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

B. Системы на основе репозиториев

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

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

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

Базы данных

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

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

C. Многоуровневые системы

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

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

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

Клиент-сервер n-уровня

Уровни относятся к компонентам, которые обычно находятся на разных физических машинах. Смежные уровни в n-уровневой архитектуре часто представляют собой клиент/сервер.

Отношения запрос-ответ могут быть синхронными или
асинхронными.

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

Преимущества многоуровневой архитектуры.

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

D. Системы на основе интерпретаторов

В систему встроен Интерпретатор, который позволяет MS Excel проводить расчет по формуле «во время выполнения». Системы используют интерпретаторы для управления программируемыми действиями, указанными пользователем. Недостаток интерпретаторов может быть медленным.

E. Системы потока данных

Системы потока данных включают ряд преобразований наборов данных. Данные преобразуются из одной формы в другую с помощью различных типов операций.

Трубы и фильтры в архитектурном стиле

Данные будут перемещаться из источника данных, а затем преобразовываться каждым фильтром. Каждый фильтр ведет себя как функция, которая преобразует данные, чтобы при необходимости их можно было использовать повторно.

Преимущества использования архитектуры конвейера и фильтра включают в себя:

  • Слабое и гибкое соединение компонентов. Каждый фильтр работает независимо от других фильтров, что позволяет легко добавлять новые фильтры, перемещать фильтры или заменять отдельные фильтры в системе.
  • Фильтры можно рассматривать как черные ящики.
  • Повторное использование. Каждый фильтр можно вызывать и использовать снова и снова
    с разными входными данными.

Недостатки использования архитектуры канала и фильтра включают в себя:

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

F. Системы неявного вызова

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

на основе событий

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

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

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

G. Системы управления технологическим процессом

Петли обратной связи

Цикл обратной связи является одной из самых основных форм управления технологическим процессом. Он состоит из четырех основных компонентов: датчика, контроллера, исполнительного механизма и самого процесса. Датчик отслеживает какую-то важную информацию. Контроллер — это логика системы. Актуатор — это физический метод управления процессом. Процесс – это то, что пытаются контролировать.

Существуют также варианты, такие как замкнутый цикл, разомкнутый цикл и прямая связь.

МАПЭ-К

Мониторинг-Анализ-План-Выполнение-Знание. Мониторы — это компоненты, взаимодействующие с датчиками. Компонент Анализ проанализирует данные, а затем компонент план решит, что делать на основе знаний (модели). Затем решение трансформировалось в исполнение. Этот тип архитектуры обычно используется в роботизированных или автоматических транспортных средствах, таких как беспилотный автомобиль.

Источник всех изображений — скриншот из курсовой заметки.

Информация: GDP Labs нанимает 1000 отличных инженеров, зарегистрируйтесь на https://career.catapa.com/gdplabs/jobs!