Performances de MVC

Le concept MVC est utilisé afin de créer des ensembles de composants systèmes. Il per-met d’isoler les composants les uns des autres, autant que possible. Ce qui facilite la tâche du concepteur de l’application pour comprendre et modifier une unité particulière, sans l’obligation de tout savoir sur les autres.

Afin de rendre les performances du pattern MVC plus concrètes, nous allons par la suite en présenter une utilisation particulière : soutenir le développement de logiciels graphiques hau-tement interactifs. L’exemple du GUI7a été choisi car c’est le plus démonstratif des exemples, mais aussi parce que dans notre contexte d’usage, nous parlons d’éléments architecturaux et programmatiques, et les avantages espérés de notre proposition seront proches de ceux conférés par ce cadre d’utilisation du pattern MVC.

Réduire la complexité des GUI par MVC

Le paradigme MVC est utilisé comme suit dans les GUI :

• Le Modèle gère le comportement et les données du domaine de l’application, répondant

aux demandes d’informations sur son état (généralement à partir de la Vue) et à des instructions pour changer d’état (habituellement de la part du Contrôleur). Il ne contient aucune information concernant l’état du GUI et ne propose aucun service spécifique à des Vues particulières et à des Contrôleurs : il est indépendant.

• La Vue gère l’affichage graphique et/ou textuel de la partie de l’écran allouée à son

application. Elle affiche les données du Modèle et lui demande des mises à jour.

7Graphical User Interface, c’est-à-dire un environnement graphique qui fournit un cadre de travail simplifiant

est nécessaire.

• Forces : Un framework générique d’interface utilisateur a besoin de travailler avec le

code de domaine.

• Solution : Créer un modèle spécifique au domaine, connecté à un affichage d’interface

utilisateur. Le point de vue est alors géré par un contrôleur. Le pattern MVC résout ce problème de création en divisant l’application en trois parties :

– Le Modèle, qui contient les données et la logique du domaine. – La Vue, interface entre l’utilisateur et le système.

– Le Contrôleur, gérant les interactions entre l’interface (Vue) et les données

(Mo-dèle).

• Contexte résultant : On a une interface utilisateur avec un modèle clairement séparé,

spécifique au domaine, la vue de l’interface utilisateur et le contrôleur.

• Rationnel : Il est indispensable de séparer le code de l’interface utilisateur du code

spécifique au domaine.

L’implémentation de MVC en Smalltalk [Burbeck, 1987] a inspiré beaucoup d’autres fra-meworks GUI. Si on considère la classeButtonen Swing de Java [Stelting et Maassen, 2002] utilisée pour représenter un bouton simple, Swing utilise une adaptation de MVC dans la-quelle la Vue et le Contrôleur sont combinés en un même objet appelé "Delegate" (Figure 4.8, d’après Oracle8et DFKI9). Cette adaptation classique permet de simplifier la communica-tion entre Vue et Contrôleur. La classeButton(Tableau 4.1) est associée à un "implementor" ButtonModelpour leModèle. Il encapsule les états internes d’un bouton et définit son

com-8Oracle Corporation, http://www.oracle.com/technetwork/java/architecture-142923.html (Page consultée le 1erfévrier 2013).

9German Research Center for Artificial Intelligence, DFKI GmbH, http://www.dfki.uni-kl.de/km/java/ (Page consultée le 1erfévrier 2013).

portement. La classeButtonest aussi associée àButtonUIpour saVue, et éventuellement à

un ou plus "event handlers" pour sonContrôleur.

(a) MVC dans Swing (b) Différence entre Swing et AWT

FIGURE4.8 – MVC dans Swing

Figure

TABLE4.1 – Exemple de MVC dans un "component" GUI Désignation Buttonen Swing

Modèle ButtonModel

Vue La représentation vi-suelle deButtonUI Contrôleur Les "handlers" de

ButtonUI

Tableau

Presque tous les éléments complexes d’un GUI dans Swing utilisent le modèle MVC au niveau du composant pour d’excellentes raisons, mais la plus importante est qu’il est hautement réutilisable, "personnalisable" et "connectable" à d’autres composants.

Avantages & Inconvénients de MVC

La liste des avantages de MVC est longue et dépend souvent du contexte. Nous en propo-sons une sélection :

l’une ou l’autre équipe.

• Vues et Contrôleurs substituables : Différents Contrôleurs et Vues peuvent être utilisés

pour le même Modèle afin de fournir une autre interface. Par exemple, les mêmes données seront vues comme un camembert ou un graphique à barres. En raison de cet avantage, MVC, très flexible, constitue un outil puissant pour la représentation des connaissances.

• Vues multiples et synchronisées du même modèle : Différents Contrôleurs et Vues

sont utilisables pour un unique Modèle en même temps, en raison de la séparation du Modèle de la Vue. Chaque Vue présente simultanément, indépendamment et de façon synchronisée les mêmes informations à partir du Modèle.

• Vues pluggables¹⁰: MVC permet de fabriquer des composants UI, structurés en une

hiérarchie complexe dans une GUI. Ces composants encouragent la réutilisation et réduisent le nombre de sous-classes spéciales.

Parmi les autres avantages que nous ne détaillerons pas, signalons : Le "Look and Feel" mo-difiable facilement, la possibilité de mettre en place un framework automatisant le processus, la capacité des MVC de se trouver à la fois au niveau micro (widgets, composants unitaires. . .) et macro (application. . .). . .

MVC apporte les bénéfices qu’apportent les bonnes pratiques de la POO. Elle décourage les répétitions inutiles de code et améliore sa réutilisation et sa maintenabilité.

Cependant, il est important de savoir que cette architecture présente aussi les mêmes inconvénients que les Design Patterns de manière générale. En outre, des difficultés de concep-tion peuvent se présenter au moment de l’implémentaconcep-tion lorsque les différentes équipes ne sont pas coordonnées (par rapport à l’interfaçage). Parfois il est nécessaire de faire évoluer le pattern pour qu’il s’applique au cas précis d’utilisation.

4.3.3 Synthèse

Les utilisations de MVC (et de ses variantes) montrent que ce pattern peut gérer la com-plexité, la flexibilité et la capacité d’évolution d’une application riche. De plus, le mécanisme de MVC se révèle d’une grande souplesse malgré l’énorme quantité de données, la réutilisation et l’adaptation des précédents composants et le développement parallèle coopératif.

Ce sont des fonctionnalités très utiles pendant et après le développement des applications. Ce pattern a été testé avec succès dans plusieurs grands projets logiciels et techniques de développement. Il existe même une adaptation des agents dans l’IHM avec les modèles PAC et AMF. Aussi, notre démarche part du questionnement suivant : Pourquoi ne pas s’inspirer de ces technologies IHM pour faciliter la formalisation des agents ?

Si nous nous tenions à la présentation de la Section 4.3.2, le paradigme MVC ne serait utilisé que pour isoler l’interface utilisateur (UI) – en général, le GUI – de la logique de domaine de l’application, comme sur l’architecture logicielle de certains SMA, dans la programmation événementielle.

La définition originale [Bodker, 1991] de l’interface utilisateur montre qu’une UI est une

surface d’interaction entre l’utilisateur et la machine. En extrapolant cette définition, en

l’adaptant au monde agent, nous pouvons convenir que la machine est un agent particulier et que "les utilisateurs" sont en fait des agents qui interagissent entre eux : la surface d’interaction sur un tel agent sera donc sa partie "visible", accessible aux autres agents !

Le plus souvent, à l’heure actuelle, construire un agent ressemble à développer une appli-cation multifenêtre multivariable dans un processus monolithique, sans outils véritablement efficaces. Notre proposition consiste à adapter MVC de la POO au SMA, en prenant en compte les caractéristiques particulières des agents. Nous avons appelé le résultat de cette adaptation : le patternagent MVC (aMVC) (agent MVC).