Interaktionsorientierte Architektur

Das Hauptziel einer interaktionsorientierten Architektur besteht darin, die Interaktion des Benutzers von der Datenabstraktion und der Geschäftsdatenverarbeitung zu trennen. Die interaktionsorientierte Softwarearchitektur zerlegt das System in drei Hauptpartitionen:

• Data module - Das Datenmodul liefert die Datenabstraktion und die gesamte Geschäftslogik.

• Control module - Das Steuermodul identifiziert den Ablauf der Steuerungs- und Systemkonfigurationsaktionen.

• View presentation module - Das Präsentationsmodul anzeigen ist für die visuelle oder akustische Präsentation der Datenausgabe verantwortlich und bietet auch eine Schnittstelle für Benutzereingaben.

Interaktionsorientierte Architektur hat zwei Hauptstile - Model-View-Controller (MVC) und Presentation-Abstraction-Control(PAC). Sowohl MVC als auch PAC schlagen eine Zerlegung von drei Komponenten vor und werden für interaktive Anwendungen wie Webanwendungen mit mehreren Gesprächen und Benutzerinteraktionen verwendet. Sie unterscheiden sich in ihrem Kontroll- und Organisationsfluss. PAC ist eine agentenbasierte hierarchische Architektur, MVC hat jedoch keine klare hierarchische Struktur.

Model-View-Controller (MVC)

MVC zerlegt eine bestimmte Softwareanwendung in drei miteinander verbundene Teile, die dazu beitragen, die internen Darstellungen von Informationen von den Informationen zu trennen, die dem Benutzer präsentiert oder von ihm akzeptiert werden.

Modul	Funktion
Modell	Kapselung der zugrunde liegenden Daten und Geschäftslogik
Regler	Reagieren Sie auf Benutzeraktionen und leiten Sie den Anwendungsfluss
Aussicht	Formatiert und präsentiert die Daten vom Modell zum Benutzer.

Modell

Das Modell ist eine zentrale Komponente von MVC, die die Daten, die Logik und die Einschränkungen einer Anwendung direkt verwaltet. Es besteht aus Datenkomponenten, die die Rohdaten der Anwendung und die Anwendungslogik für die Schnittstelle verwalten.

• Es ist eine unabhängige Benutzeroberfläche und erfasst das Verhalten der Anwendungsproblemdomäne.

• Es ist die domänenspezifische Software-Simulation oder Implementierung der zentralen Struktur der Anwendung.

• Wenn sich der Status geändert hat, benachrichtigt es die zugehörige Ansicht, um eine aktualisierte Ausgabe zu erstellen, und die Steuerung, um den verfügbaren Befehlssatz zu ändern.

Aussicht

Die Ansicht kann verwendet werden, um jede Ausgabe von Informationen in grafischer Form wie Diagramm oder Diagramm darzustellen. Es besteht aus Präsentationskomponenten, die die visuelle Darstellung von Daten liefern

• Ansichten fordern Informationen von ihrem Modell an und generieren eine Ausgabedarstellung für den Benutzer.

• Es sind mehrere Ansichten derselben Informationen möglich, z. B. ein Balkendiagramm für die Verwaltung und eine tabellarische Ansicht für Buchhalter.

Regler

Ein Controller akzeptiert eine Eingabe und konvertiert sie in Befehle für das Modell oder die Ansicht. Es besteht aus Eingabeverarbeitungskomponenten, die Eingaben des Benutzers durch Ändern des Modells verarbeiten.

• Es fungiert als Schnittstelle zwischen den zugehörigen Modellen und Ansichten und den Eingabegeräten.

• Es kann Befehle an das Modell senden, um den Status des Modells zu aktualisieren, und an die zugehörige Ansicht, um die Darstellung des Modells in der Ansicht zu ändern.

MVC - ich

Es ist eine einfache Version der MVC-Architektur, bei der das System in zwei Subsysteme unterteilt ist:

• The Controller-View - Die Controller-Ansicht fungiert als Eingabe- / Ausgabeschnittstelle und die Verarbeitung ist abgeschlossen.

• The Model - Das Modell bietet alle Daten- und Domänendienste.

MVC-I Architecture

Das Modellmodul benachrichtigt das Controller-View-Modul über Datenänderungen, sodass die Grafikdatenanzeige entsprechend geändert wird. Die Steuerung ergreift auch geeignete Maßnahmen bei den Änderungen.

Die Verbindung zwischen Controller-Ansicht und Modell kann in einem Muster (wie im obigen Bild gezeigt) von Subscribe-Notify entworfen werden, wobei die Controller-Ansicht das Modell abonniert und Model die Controller-Ansicht über Änderungen benachrichtigt.

MVC - II

MVC-II ist eine Erweiterung der MVC-I-Architektur, bei der das Ansichtsmodul und das Controller-Modul getrennt sind. Das Modellmodul spielt eine aktive Rolle wie in MVC-I, indem es alle Kernfunktionen und Daten bereitstellt, die von der Datenbank unterstützt werden.

Das Ansichtsmodul präsentiert Daten, während das Steuerungsmodul Eingabeanforderungen akzeptiert, Eingabedaten validiert, das Modell, die Ansicht und ihre Verbindung initiiert und die Aufgabe auch versendet.

MVC-II Architecture

MVC-Anwendungen

MVC-Anwendungen sind effektiv für interaktive Anwendungen, bei denen mehrere Ansichten für ein einzelnes Datenmodell erforderlich sind und einfach eine neue oder geänderte Schnittstellenansicht eingefügt werden können.

MVC-Anwendungen eignen sich für Anwendungen, bei denen zwischen den Modulen klare Unterteilungen bestehen, sodass verschiedene Fachkräfte zugewiesen werden können, um gleichzeitig an verschiedenen Aspekten solcher Anwendungen zu arbeiten.

Advantages

• Es sind viele MVC Vendor Framework-Toolkits verfügbar.

• Mehrere Ansichten mit demselben Datenmodell synchronisiert.

• Einfaches Einstecken neuer oder Ersetzen von Schnittstellenansichten.

• Wird für die Anwendungsentwicklung verwendet, bei der Grafikfachleute, Programmierer und Datenbankentwickler in einem entworfenen Projektteam arbeiten.

Disadvantages

• Nicht geeignet für agentenorientierte Anwendungen wie interaktive Mobil- und Robotikanwendungen.

• Mehrere Paare von Controllern und Ansichten, die auf demselben Datenmodell basieren, verteuern jede Änderung des Datenmodells.

• Die Trennung zwischen der Ansicht und dem Controller ist in einigen Fällen nicht klar.

Presentation-Abstraction-Control (PAC)

In PAC ist das System in einer Hierarchie vieler kooperierender Agenten (Triaden) angeordnet. Es wurde von MVC entwickelt, um die Anwendungsanforderungen mehrerer Agenten zusätzlich zu interaktiven Anforderungen zu unterstützen.

Jeder Agent besteht aus drei Komponenten:

• The presentation component - Formatiert die visuelle und akustische Darstellung von Daten.

• The abstraction component - Ruft die Daten ab und verarbeitet sie.

• The control component - Erledigt die Aufgabe wie den Kontroll- und Kommunikationsfluss zwischen den beiden anderen Komponenten.

Die PAC-Architektur ähnelt MVC in dem Sinne, dass das Präsentationsmodul dem Ansichtsmodul von MVC ähnelt. Das Abstraktionsmodul sieht aus wie das Modellmodul von MVC und das Steuermodul ist wie das Steuerungsmodul von MVC, unterscheidet sich jedoch in ihrem Steuerungs- und Organisationsfluss.

In jedem Agenten gibt es keine direkten Verbindungen zwischen Abstraktionskomponente und Präsentationskomponente. Die Steuerkomponente in jedem Agenten ist für die Kommunikation mit anderen Agenten verantwortlich.

Die folgende Abbildung zeigt ein Blockdiagramm für einen einzelnen Agenten im PAC-Design.

PAC mit mehreren Agenten

In PACs, die aus mehreren Agenten bestehen, stellt der Agent der obersten Ebene Kerndaten und Geschäftslogiken bereit. Die Agenten der untersten Ebene definieren detaillierte spezifische Daten und Präsentationen. Der Agent der mittleren oder mittleren Ebene fungiert als Koordinator der Agenten der unteren Ebene.

• Jeder Agent hat seinen eigenen zugewiesenen Job.

• Für einige Agenten der mittleren Ebene sind die interaktiven Präsentationen nicht erforderlich, sodass sie keine Präsentationskomponente haben.

• Die Steuerungskomponente wird für alle Agenten benötigt, über die alle Agenten miteinander kommunizieren.

Die folgende Abbildung zeigt die mehreren Agenten, die an PAC teilnehmen.

Applications

• Wirksam für ein interaktives System, bei dem das System hierarchisch in viele kooperierende Agenten zerlegt werden kann.

• Wirksam, wenn erwartet wird, dass die Kopplung zwischen den Agenten locker ist, so dass Änderungen an einem Agenten andere nicht beeinflussen.

• Effektiv für verteilte Systeme, bei denen alle Agenten entfernt verteilt sind und jeder seine eigenen Funktionen mit Daten und interaktiver Schnittstelle hat.

• Geeignet für Anwendungen mit umfangreichen GUI-Komponenten, bei denen jede ihre eigenen aktuellen Daten und ihre interaktive Schnittstelle behält und mit anderen Komponenten kommunizieren muss.

Vorteile

• Unterstützung für Multitasking und Multi-Viewing

• Unterstützung für die Wiederverwendbarkeit und Erweiterbarkeit von Agenten

• Einfach, einen neuen Agenten anzuschließen oder einen vorhandenen zu ändern

• Unterstützung für Parallelität, wenn mehrere Agenten gleichzeitig in verschiedenen Threads oder auf verschiedenen Geräten oder Computern ausgeführt werden

Nachteile

• Overhead aufgrund der Kontrollbrücke zwischen Präsentation und Abstraktion und der Kommunikation von Kontrollen zwischen Agenten.

• Aufgrund der losen Kopplung und der hohen Unabhängigkeit zwischen den Agenten ist es schwierig, die richtige Anzahl von Agenten zu bestimmen.

• Die vollständige Trennung von Präsentation und Abstraktion durch Kontrolle in jedem Agenten führt zu Entwicklungskomplexität, da die Kommunikation zwischen Agenten nur zwischen den Kontrollen der Agenten stattfindet