Architecture orientée interaction

L'objectif principal de l'architecture orientée interaction est de séparer l'interaction de l'utilisateur de l'abstraction des données et du traitement des données métier. L'architecture logicielle orientée interaction décompose le système en trois partitions principales -

  • Data module - Le module de données fournit l'abstraction des données et toute la logique métier.

  • Control module - Le module de contrôle identifie le flux des actions de contrôle et de configuration du système.

  • View presentation module - Le module de présentation de vue est responsable de la présentation visuelle ou audio de la sortie de données et il fournit également une interface pour l'entrée utilisateur.

L'architecture orientée interaction a deux styles principaux - Model-View-Controller (MVC) et Presentation-Abstraction-Control(PAC). MVC et PAC proposent tous deux une décomposition en trois composants et sont utilisés pour des applications interactives telles que des applications Web avec de multiples discussions et interactions utilisateur. Ils sont différents dans leur flux de contrôle et leur organisation. PAC est une architecture hiérarchique basée sur des agents mais MVC n'a pas de structure hiérarchique claire.

Model-View-Controller (MVC)

MVC décompose une application logicielle donnée en trois parties interconnectées qui aident à séparer les représentations internes des informations des informations présentées à ou acceptées par l'utilisateur.

Module Fonction
Modèle Encapsulation des données sous-jacentes et de la logique métier
Manette Répondre à l'action de l'utilisateur et diriger le flux de l'application
Vue Formate et présente les données du modèle à l'utilisateur.

Modèle

Le modèle est un composant central de MVC qui gère directement les données, la logique et les contraintes d'une application. Il se compose de composants de données, qui maintiennent les données brutes de l'application et la logique d'application pour l'interface.

  • Il s'agit d'une interface utilisateur indépendante et capture le comportement du domaine de problème d'application.

  • Il s'agit de la simulation logicielle spécifique au domaine ou de l'implémentation de la structure centrale de l'application.

  • Lorsqu'il y a eu un changement dans son état, il donne une notification à sa vue associée pour produire une sortie mise à jour et au contrôleur pour changer l'ensemble de commandes disponibles.

Vue

La vue peut être utilisée pour représenter n'importe quelle sortie d'informations sous forme graphique telle qu'un diagramme ou un graphique. Il se compose de composants de présentation qui fournissent les représentations visuelles des données

  • Les vues demandent des informations à leur modèle et génèrent une représentation de sortie pour l'utilisateur.

  • Plusieurs vues des mêmes informations sont possibles, comme un diagramme à barres pour la gestion et une vue tabulaire pour les comptables.

Manette

Un contrôleur accepte une entrée et la convertit en commandes pour le modèle ou la vue. Il se compose de composants de traitement d'entrée qui gèrent les entrées de l'utilisateur en modifiant le modèle.

  • Il agit comme une interface entre les modèles et vues associés et les périphériques d'entrée.

  • Il peut envoyer des commandes au modèle pour mettre à jour l'état du modèle et à sa vue associée pour modifier la présentation de la vue du modèle.

MVC - I

C'est une version simple de l'architecture MVC où le système est divisé en deux sous-systèmes -

  • The Controller-View - La vue du contrôleur agit comme une interface d'entrée / sortie et le traitement est effectué.

  • The Model - Le modèle fournit tous les services de données et de domaine.

MVC-I Architecture

Le module de modèle informe le module de visualisation de l'automate de tout changement de données afin que tout affichage de données graphiques soit modifié en conséquence. Le contrôleur prend également les mesures appropriées suite aux modifications.

La connexion entre la vue contrôleur et le modèle peut être conçue dans un modèle (comme indiqué dans l'image ci-dessus) de souscription-notification par lequel la vue contrôleur s'abonne au modèle et le modèle notifie la vue contrôleur de tout changement.

MVC - II

MVC – II est une amélioration de l'architecture MVC-I dans laquelle le module de vue et le module de contrôleur sont séparés. Le module de modèle joue un rôle actif comme dans MVC-I en fournissant toutes les fonctionnalités de base et les données prises en charge par la base de données.

Le module de vue présente les données tandis que le module de contrôleur accepte la demande d'entrée, valide les données d'entrée, lance le modèle, la vue, leur connexion et distribue également la tâche.

MVC-II Architecture

Applications MVC

Les applications MVC sont efficaces pour les applications interactives où plusieurs vues sont nécessaires pour un seul modèle de données et faciles à brancher une nouvelle vue d'interface ou la modifier.

Les applications MVC sont adaptées aux applications où il existe des divisions claires entre les modules afin que différents professionnels puissent être affectés à travailler simultanément sur différents aspects de ces applications.

Advantages

  • Il existe de nombreuses boîtes à outils de framework de fournisseur MVC disponibles.

  • Plusieurs vues synchronisées avec le même modèle de données.

  • Facile à brancher de nouvelles vues d'interface ou à remplacer.

  • Utilisé pour le développement d'applications où les professionnels de l'expertise graphique, les professionnels de la programmation et les professionnels du développement de bases de données travaillent dans une équipe de projet conçue.

Disadvantages

  • Ne convient pas aux applications orientées agent telles que les applications mobiles interactives et robotiques.

  • Plusieurs paires de contrôleurs et de vues basées sur le même modèle de données rendent tout changement de modèle de données coûteux.

  • La division entre la vue et le contrôleur n'est pas claire dans certains cas.

Présentation-Abstraction-Contrôle (PAC)

Dans PAC, le système est organisé en une hiérarchie de nombreux agents coopérants (triades). Il a été développé à partir de MVC pour prendre en charge les exigences d'application de plusieurs agents en plus des exigences interactives.

Chaque agent a trois composants -

  • The presentation component - Formate la présentation visuelle et audio des données.

  • The abstraction component - Récupère et traite les données.

  • The control component - Gère la tâche telle que le flux de contrôle et la communication entre les deux autres composants.

L'architecture PAC est similaire à MVC, en ce sens que le module de présentation est comme le module d'affichage de MVC. Le module d'abstraction ressemble au module modèle de MVC et le module de contrôle est comme le module contrôleur de MVC, mais ils diffèrent dans leur flux de contrôle et d'organisation.

Il n'y a pas de connexions directes entre le composant d'abstraction et le composant de présentation dans chaque agent. Le composant de contrôle de chaque agent est chargé des communications avec les autres agents.

La figure suivante montre un schéma de principe pour un seul agent dans la conception PAC.

PAC avec plusieurs agents

Dans les PAC composés de plusieurs agents, l'agent de niveau supérieur fournit les données de base et les logiques métier. Les agents de niveau inférieur définissent des données et des présentations spécifiques détaillées. L'agent de niveau intermédiaire ou intermédiaire agit en tant que coordinateur des agents de bas niveau.

  • Chaque agent a son propre travail assigné.

  • Pour certains agents de niveau intermédiaire, les présentations interactives ne sont pas nécessaires, ils n'ont donc pas de composant de présentation.

  • Le composant de contrôle est requis pour tous les agents par l'intermédiaire desquels tous les agents communiquent entre eux.

La figure suivante montre les agents multiples qui participent au PAC.

Applications

  • Efficace pour un système interactif où le système peut être décomposé en de nombreux agents coopérants de manière hiérarchique.

  • Efficace lorsque l'on s'attend à ce que le couplage entre les agents soit lâche de sorte que les changements sur un agent n'affectent pas les autres.

  • Efficace pour un système distribué où tous les agents sont distribués à distance et chacun d'eux a ses propres fonctionnalités avec des données et une interface interactive.

  • Convient aux applications avec des composants GUI riches où chacun d'entre eux conserve ses propres données actuelles et interface interactive et doit communiquer avec d'autres composants.

Avantages

  • Prise en charge du multitâche et du multi-affichage

  • Prise en charge de la réutilisabilité et de l'extensibilité des agents

  • Facile à brancher un nouvel agent ou à changer un agent existant

  • Prise en charge de l'accès concurrentiel où plusieurs agents s'exécutent en parallèle dans différents threads ou différents périphériques ou ordinateurs

Désavantages

  • Frais généraux dus au pont de contrôle entre la présentation et l'abstraction et à la communication des contrôles entre agents.

  • Difficile de déterminer le bon nombre d'agents en raison d'un couplage lâche et d'une grande indépendance entre les agents.

  • La séparation complète de la présentation et de l'abstraction par le contrôle dans chaque agent génère une complexité de développement puisque les communications entre agents n'ont lieu qu'entre les contrôles des agents