Архитектура, ориентированная на взаимодействие

Основная цель архитектуры, ориентированной на взаимодействие, - отделить взаимодействие пользователя от абстракции данных и обработки бизнес-данных. Архитектура программного обеспечения, ориентированная на взаимодействие, разбивает систему на три основных раздела:

Data module - Модуль данных обеспечивает абстракцию данных и всю бизнес-логику.
Control module - Модуль управления определяет последовательность действий по управлению и конфигурации системы.
View presentation module - Модуль представления представления отвечает за визуальное или звуковое представление вывода данных, а также предоставляет интерфейс для ввода данных пользователем.

Архитектура, ориентированная на взаимодействие, имеет два основных стиля: Model-View-Controller (MVC) и Presentation-Abstraction-Control(PAC). И MVC, и PAC предлагают трехкомпонентную декомпозицию и используются для интерактивных приложений, таких как веб-приложения с несколькими разговорами и взаимодействиями с пользователем. Они разные по своему контролю и организации. PAC - это иерархическая архитектура на основе агентов, но MVC не имеет четкой иерархической структуры.

Модель-представление-контроллер (MVC)

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

Модуль	Функция
Модель	Инкапсуляция базовых данных и бизнес-логики
Контроллер	Реагируйте на действия пользователя и направляйте поток приложения
Посмотреть	Форматирует и представляет данные от модели к пользователю.

Модель

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

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

Посмотреть

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

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

Контроллер

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

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

MVC - I

Это простая версия архитектуры MVC, в которой система разделена на две подсистемы:

The Controller-View - Представление контроллера действует как интерфейс ввода / вывода, и обработка выполняется.
The Model - Модель предоставляет все данные и сервисы домена.

MVC-I Architecture

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

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

MVC - II

MVC – II - это усовершенствованная архитектура MVC-I, в которой модуль представления и модуль контроллера разделены. Модуль модели играет активную роль, как и в MVC-I, предоставляя все основные функции и данные, поддерживаемые базой данных.

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

MVC-II Architecture

Приложения MVC

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

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

Advantages

Доступно множество наборов инструментов для платформы MVC.
Несколько представлений синхронизированы с одной и той же моделью данных.
Легко добавлять новые или заменять виды интерфейса.
Используется для разработки приложений, где профессионалы в области графики, программисты и специалисты по разработке баз данных работают в спроектированной проектной группе.

Disadvantages

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

Презентация-Абстракция-Управление (PAC)

В PAC система организована в виде иерархии многих взаимодействующих агентов (триад). Он был разработан на основе MVC для поддержки требований приложения нескольких агентов в дополнение к интерактивным требованиям.

Каждый агент состоит из трех компонентов -

The presentation component - Форматирует визуальное и звуковое представление данных.
The abstraction component - Извлекает и обрабатывает данные.
The control component - Обрабатывает такую задачу, как поток управления и связь между двумя другими компонентами.

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

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

На следующем рисунке показана блок-схема для одного агента в проекте PAC.

PAC с несколькими агентами

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

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

На следующем рисунке показано несколько агентов, участвующих в PAC.

Applications

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

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

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

Недостатки

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