Architektura zorientowana na interakcje

Podstawowym celem architektury zorientowanej na interakcję jest oddzielenie interakcji użytkownika od abstrakcji i przetwarzania danych biznesowych. Architektura oprogramowania zorientowana na interakcję rozkłada system na trzy główne partycje -

Data module - Moduł danych zapewnia abstrakcję danych i całą logikę biznesową.
Control module - Moduł sterujący identyfikuje przepływ działań kontrolnych i konfiguracyjnych systemu.
View presentation module - Moduł prezentacji widoku jest odpowiedzialny za wizualną lub dźwiękową prezentację danych wyjściowych, a także zapewnia interfejs do wprowadzania danych przez użytkownika.

Architektura zorientowana na interakcję ma dwa główne style - Model-View-Controller (MVC) i Presentation-Abstraction-Control(PAC). Zarówno MVC, jak i PAC proponują dekompozycję trzech komponentów i są używane w aplikacjach interaktywnych, takich jak aplikacje internetowe z wieloma rozmowami i interakcjami użytkownika. Różnią się przepływem kontroli i organizacją. PAC jest hierarchiczną architekturą opartą na agentach, ale MVC nie ma jasnej hierarchicznej struktury.

Kontroler widoku modelu (MVC)

MVC rozkłada daną aplikację na trzy połączone ze sobą części, które pomagają w oddzieleniu wewnętrznej reprezentacji informacji od informacji przedstawionych użytkownikowi lub zaakceptowanych przez użytkownika.

Moduł	Funkcjonować
Model	Hermetyzacja danych i logiki biznesowej
Kontroler	Reaguj na działanie użytkownika i kieruj przepływem aplikacji
Widok	Formatuje i przedstawia dane z modelu użytkownikowi.

Model

Model jest centralnym komponentem MVC, który bezpośrednio zarządza danymi, logiką i ograniczeniami aplikacji. Składa się z komponentów danych, które utrzymują surowe dane aplikacji i logikę aplikacji dla interfejsu.

Jest to niezależny interfejs użytkownika i rejestruje zachowanie domeny, w której występują problemy z aplikacjami.
Jest to specyficzna dla domeny symulacja oprogramowania lub implementacja centralnej struktury aplikacji.
Gdy nastąpiła zmiana w jego stanie, wysyła powiadomienie do skojarzonego z nim widoku, aby wygenerować zaktualizowane wyjście, a sterownik do zmiany dostępnego zestawu poleceń.

Widok

Widok może służyć do przedstawiania dowolnych danych wyjściowych w formie graficznej, takiej jak diagram lub wykres. Składa się z komponentów prezentacji, które zapewniają wizualną reprezentację danych

Widoki żądają informacji ze swojego modelu i generują reprezentację wyjściową dla użytkownika.
Możliwych jest wiele widoków tych samych informacji, takich jak wykres słupkowy do zarządzania i widok tabelaryczny dla księgowych.

Kontroler

Kontroler akceptuje dane wejściowe i konwertuje je na polecenia dla modelu lub widoku. Składa się z komponentów przetwarzania danych wejściowych, które obsługują dane wejściowe od użytkownika poprzez modyfikację modelu.

Działa jako interfejs między skojarzonymi modelami i widokami a urządzeniami wejściowymi.
Może wysyłać polecenia do modelu, aby zaktualizować stan modelu i do skojarzonego z nim widoku, aby zmienić prezentację modelu w widoku.

MVC - I

Jest to prosta wersja architektury MVC, w której system jest podzielony na dwa podsystemy -

The Controller-View - Widok kontrolera działa jako interfejs wejścia / wyjścia i przetwarzanie jest zakończone.
The Model - Model zapewnia wszystkie usługi związane z danymi i domeną.

MVC-I Architecture

Moduł modelu powiadamia moduł widoku sterownika o wszelkich zmianach danych, dzięki czemu wszelkie wyświetlane dane graficzne zostaną odpowiednio zmienione. Administrator podejmuje również odpowiednie działania w przypadku zmian.

Połączenie między widokiem kontrolera a modelem można zaprojektować według wzoru (jak pokazano na powyższym obrazku) powiadomienia o subskrypcji, w którym widok kontrolera subskrybuje model, a model powiadamia widok kontrolera o wszelkich zmianach.

MVC - II

MVC-II jest rozszerzeniem architektury MVC-I, w której moduł widoku i moduł kontrolera są oddzielne. Moduł modelowy odgrywa aktywną rolę, podobnie jak w MVC-I, zapewniając wszystkie podstawowe funkcje i dane obsługiwane przez bazę danych.

Moduł widoku prezentuje dane, podczas gdy moduł kontrolera przyjmuje żądanie wejścia, weryfikuje dane wejściowe, inicjuje model, widok, ich połączenie, a także wysyła zadanie.

MVC-II Architecture

Aplikacje MVC

Aplikacje MVC są efektywne w przypadku aplikacji interaktywnych, w których dla jednego modelu danych potrzeba wielu widoków i można je łatwo podłączyć do nowego lub zmienić widok interfejsu.

Aplikacje MVC są odpowiednie dla aplikacji, w których istnieją wyraźne podziały między modułami, dzięki czemu można przypisać różnych specjalistów do jednoczesnej pracy nad różnymi aspektami takich aplikacji.

Advantages

Dostępnych jest wiele zestawów narzędzi dla dostawców MVC.
Wiele widoków zsynchronizowanych z tym samym modelem danych.
Łatwe do podłączenia nowe lub zastąpienia widoków interfejsu.
Służy do tworzenia aplikacji, w których specjaliści od grafiki, specjaliści od programowania i specjaliści ds. Rozwoju baz danych pracują w zaprojektowanym zespole projektowym.

Disadvantages

Nie nadaje się do aplikacji zorientowanych na agentów, takich jak interaktywne aplikacje mobilne i robotyka.
Wiele par kontrolerów i widoków opartych na tym samym modelu danych powoduje, że każda zmiana modelu danych jest kosztowna.
W niektórych przypadkach podział między View a Controller nie jest jasny.

Kontrola prezentacji-abstrakcji (PAC)

W PAC system jest zorganizowany w hierarchię wielu współpracujących agentów (triad). Został opracowany z MVC w celu obsługi wymagań aplikacji wielu agentów, oprócz wymagań interaktywnych.

Każdy agent składa się z trzech elementów -

The presentation component - Formatuje wizualną i dźwiękową prezentację danych.
The abstraction component - Pobiera i przetwarza dane.
The control component - Obsługuje zadania, takie jak przepływ kontroli i komunikacja między pozostałymi dwoma komponentami.

Architektura PAC jest podobna do MVC, w tym sensie, że moduł prezentacji jest podobny do modułu widoku MVC. Moduł abstrakcji wygląda jak moduł modelowy MVC, a moduł sterujący jest podobny do modułu kontrolera MVC, ale różnią się przepływem kontroli i organizacją.

W każdym agencie nie ma bezpośrednich połączeń między komponentem abstrakcji a komponentem prezentacji. Komponent kontrolny w każdym agencie odpowiada za komunikację z innymi agentami.

Poniższy rysunek przedstawia schemat blokowy pojedynczego agenta w projekcie PAC.

PAC z wieloma agentami

W poświadczeniach dostępu zabezpieczonego składających się z wielu agentów agent najwyższego poziomu zapewnia podstawowe dane i logikę biznesową. Agenci najniższego poziomu definiują szczegółowe dane i prezentacje. Agent średniego lub średniego szczebla działa jako koordynator agentów niskiego poziomu.

Każdy agent ma swoje przypisane zadanie.
W przypadku niektórych agentów średniego poziomu prezentacje interaktywne nie są wymagane, więc nie mają komponentu prezentacji.
Komponent kontrolny jest wymagany dla wszystkich agentów, za pośrednictwem których wszyscy agenci komunikują się ze sobą.

Poniższy rysunek przedstawia wielu agentów biorących udział w PAC.

Applications

Skuteczny w przypadku systemu interaktywnego, w którym system można rozłożyć na wiele współpracujących agentów w sposób hierarchiczny.
Skuteczny, gdy oczekuje się, że sprzężenie między czynnikami będzie luźne, aby zmiany w czynniku nie wpływały na innych.
Skuteczny dla systemów rozproszonych, w których wszyscy agenci są zdalnie rozproszeni, a każdy z nich ma własne funkcjonalności z danymi i interaktywnym interfejsem.
Nadaje się do aplikacji z bogatymi komponentami GUI, w których każdy z nich przechowuje własne bieżące dane i interaktywny interfejs oraz musi komunikować się z innymi komponentami.

Zalety

Obsługa wielozadaniowości i wielu widoków
Obsługa możliwości ponownego użycia i rozszerzania agentów
Łatwo podłączyć nowego agenta lub zmienić istniejącego
Obsługa współbieżności, w której wielu agentów działa równolegle w różnych wątkach lub na różnych urządzeniach lub komputerach

Niedogodności

Koszty ogólne wynikające z pomostu kontrolnego między prezentacją a abstrakcją oraz komunikacją kontroli między agentami.
Trudno jest określić właściwą liczbę agentów ze względu na luźne powiązania i dużą niezależność między agentami.
Całkowite oddzielenie prezentacji i abstrakcji przez kontrolę w każdym agencie generuje złożoność programowania, ponieważ komunikacja między agentami odbywa się tylko między kontrolkami agentów