Иерархическая Архитектура

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

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

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

Иерархические архитектурные стили делятся на —

• Main-подпрограмма
• Подчиненная
• Виртуальная машина

Main-подпрограмма

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

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

Существует два способа передачи данных в качестве параметров подпрограммам, а именно:

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

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

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

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

преимущества

• Легко разложить систему на основе уточнения иерархии.

• Может использоваться в подсистеме объектно-ориентированного проектирования.

Легко разложить систему на основе уточнения иерархии.

Может использоваться в подсистеме объектно-ориентированного проектирования.

Недостатки

• Уязвимы, так как содержат глобальные данные.

• Плотное сцепление может вызвать более сильные эффекты изменений.

Уязвимы, так как содержат глобальные данные.

Плотное сцепление может вызвать более сильные эффекты изменений.

Master-Slave

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

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

Реализация шаблона Master-Slave состоит из пяти этапов:

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

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

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

• Реализуйте подчиненные компоненты в соответствии со спецификациями, разработанными на предыдущем шаге.

• Реализуйте мастер в соответствии со спецификациями, разработанными на этапах 1-3.

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

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

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

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

Реализуйте мастер в соответствии со спецификациями, разработанными на этапах 1-3.

Приложения

• Подходит для приложений, где надежность программного обеспечения является критической проблемой.

• Широко применяется в областях параллельных и распределенных вычислений.

Подходит для приложений, где надежность программного обеспечения является критической проблемой.

Широко применяется в областях параллельных и распределенных вычислений.

преимущества

• Более быстрые вычисления и легкая масштабируемость.

• Обеспечивает надежность, так как рабов можно дублировать.

• Ведомый может быть реализован по-разному, чтобы минимизировать семантические ошибки.

Более быстрые вычисления и легкая масштабируемость.

Обеспечивает надежность, так как рабов можно дублировать.

Ведомый может быть реализован по-разному, чтобы минимизировать семантические ошибки.

Недостатки

• Коммуникации накладные.

• Не все проблемы можно разделить.

• Трудно реализовать и переносимость вопроса.

Коммуникации накладные.

Не все проблемы можно разделить.

Трудно реализовать и переносимость вопроса.

Архитектура виртуальной машины

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

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

В большинстве случаев виртуальная машина отделяет язык программирования или среду приложения от платформы исполнения. Основная цель — обеспечить мобильность . Интерпретация конкретного модуля через виртуальную машину может восприниматься как —

• Механизм интерпретации выбирает инструкцию из модуля, который интерпретируется.

• На основании инструкции механизм обновляет внутреннее состояние виртуальной машины, и вышеописанный процесс повторяется.

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

На основании инструкции механизм обновляет внутреннее состояние виртуальной машины, и вышеописанный процесс повторяется.

На следующем рисунке показана архитектура стандартной инфраструктуры виртуальных машин на одном физическом компьютере.

Гипервизор, также называемый монитором виртуальной машины , работает в операционной системе хоста и распределяет соответствующие ресурсы для каждой гостевой ОС. Когда гость выполняет системный вызов, гипервизор перехватывает и переводит его в соответствующий системный вызов, поддерживаемый операционной системой хоста. Гипервизор контролирует доступ каждой виртуальной машины к ЦП, памяти, постоянному хранилищу, устройствам ввода-вывода и сети.

Приложения

Архитектура виртуальной машины подходит в следующих областях:

• Подходит для решения проблемы с помощью симуляции или перевода, если нет прямого решения.

• Примеры приложений включают интерпретаторы микропрограммирования, обработки XML, выполнения языка команд сценариев, выполнения системы на основе правил, язык программирования Smalltalk и Java для интерпретаторов.

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

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

Примеры приложений включают интерпретаторы микропрограммирования, обработки XML, выполнения языка команд сценариев, выполнения системы на основе правил, язык программирования Smalltalk и Java для интерпретаторов.

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

преимущества

• Переносимость и независимость от платформы.

• Простота разработки программного обеспечения.

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

• Моделирование для работающей модели бедствия.

• Внесите изменения во время выполнения.

Переносимость и независимость от платформы.

Простота разработки программного обеспечения.

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

Моделирование для работающей модели бедствия.

Внесите изменения во время выполнения.

Недостатки

• Медленное выполнение переводчика из-за характера переводчика.

• Производительность снижается из-за дополнительных вычислений, связанных с выполнением.

Медленное выполнение переводчика из-за характера переводчика.

Производительность снижается из-за дополнительных вычислений, связанных с выполнением.

Слоистый стиль

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

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

• Каждый уровень предоставляет услуги для уровня выше и служит в качестве клиента для уровня ниже, то есть запрос к уровню i +1 вызывает службы, предоставляемые уровнем i, через интерфейс уровня i. Ответ может вернуться к уровню i +1, если задача выполнена; в противном случае уровень i постоянно вызывает службы из уровня i -1 ниже.

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

Каждый уровень предоставляет услуги для уровня выше и служит в качестве клиента для уровня ниже, то есть запрос к уровню i +1 вызывает службы, предоставляемые уровнем i, через интерфейс уровня i. Ответ может вернуться к уровню i +1, если задача выполнена; в противном случае уровень i постоянно вызывает службы из уровня i -1 ниже.

Приложения

Слоистый стиль подходит в следующих областях —

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

Любое приложение, которое можно разложить на части, специфичные для приложения и платформы.

Приложения, которые имеют четкое разделение между основными службами, критическими службами и службами пользовательского интерфейса и т. Д.

Дизайн основан на дополнительных уровнях абстракции.

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

Разделение стандартного интерфейса и его реализация.

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

Каждый уровень может быть абстрактной машиной, развернутой независимо, которая поддерживает мобильность.

Простая декомпозиция системы на основе определения задач в нисходящем порядке

Различные реализации (с идентичными интерфейсами) одного и того же уровня могут использоваться взаимозаменяемо

Многие приложения или системы нелегко структурированы.

Более низкая производительность во время выполнения, поскольку запрос клиента или ответ клиенту должны проходить через несколько уровней.

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

Открытие межслойной связи может привести к взаимоблокировке, а «шунтирование» может вызвать сильную связь.

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