Mise en uvre

Si nous réexaminons les objectifs concernant la mise en uvre, discutés dans la section précédente, nous retrouvons très naturellement le principe de séparation des intérêts (separation of concerns) dans une conception orientée objet. Un modèle garde l'information sémique issue des interprétations ; différentes vues utilisent ces informations et les modifient. Le modèle n'est pas directement responsable pour les différentes vues ; ceci doit être contrôlé par un intermédiaire (donc un contrôleur). Ce dernier permet de construire indépendamment le modèle et plus tard ajouter ou modifier les vues, c.-à-d. les manières dont on peut utiliser les données du modèle.

La modularité d'une telle approche étant très estimée dans le monde de l'ingénierie orientée objet, on a essayé de standardiser cette conception modulaire. On utilise souvent le terme patron (design pattern) pour parler de schémas abstraits et plus ou moins standardisés, récurrents à travers les modélisations objet, cf. [45]. Initialement introduit pour la création des interfaces utilisateur dans Smalltalk-80, [32], [42], le patron de conception objet appelé MVC (Model, View, Controller) a été commenté, critiqué, détaillé, modifié (cf. MLP ou Model, Logical view, Physical view, [7], ou bien le patron Mediator, [27]) et, surtout, largement utilisé depuis.

Le principal apport de MVC est l'introduction d'une séparation entre la partie concernant le modèle de l'application (c.-à-d. la structure logique des données utilisées par l'application) et les différentes vues sur le modèle, notamment les interfaces utilisateur qui manipulent les structures de données. Un modèle peut avoir plusieurs vues, selon les besoins de l'application. Une vue est responsable de la présentation des données tandis que le modèle n'en est pas forcément << au courant >>. Le rôle du contrôleur est précisément de faire la connexion entre le modèle et une vue. Un exemple simple mais représentatif derrière cette philosophie est montré dans la figure5.1

  

Figure 5.1: Une simple démonstration de la séparation entre le modèle et un ensemble de vues sur ce modèle. Dans le cas général, une vue peut aussi modifier les données dans le modèle

Les extensions et modifications du patron MVC initial concernent surtout une meilleure définition des responsabilités du contrôleur.

Par exemple, l'apport de l'adaptation MLP, est une meilleure explicitation de la communication entre les trois parties ; la philosophie derrière l'approche reste la même (e.g. la partie Vue logique de MLP correspond bien au contrôleur de MVC, et la partie Vue physique à la partie Vue de MVC, [7]). Par ailleurs, le patron Mediator [27], propose la mise en collaboration d'un ensemble de contrôleurs simples à l'aide d'un hyper-contrôleur dont le rôle principal est de déléguer les responsabilités et de faire collaborer les contrôleurs partiels.

Dans tous les cas, la philosophie principale reste la même : séparer les responsabilités pour mieux concevoir, tester, maintenir, modifier et faire évoluer.

Selon les objectifs applicatifs que nous avons posés, nous proposons une extension de cette philosophie indépendamment d'une application particulière. Le même modèle statique, défini une seule fois, peut servir non seulement pour un certain nombre d'interfaces utilisateur au sein d'une application, mais aussi dans différentes applications. Une fois le modèle statique défini, il suffit de l'utiliser tel quel dans la modélisation objet d'une nouvelle application. Le modèle étant responsable pour la persistance et la cohérence de ses objets, l'application peut bénéficier de l'ensemble des informations sémiques disponibles qui, en plus, sont persistantes, et insister plutôt sur l'interaction avec l'utilisateur.

Si l'application demande quelques structures supplémentaires pour améliorer ses performances, alors elle les ajoute dans sa propre modélisation et c'est à elle de les actualiser, chaque fois que l'état actuel des objets du modèle change (e.g. à l'aide d'un patron Observateur/Observable, [45], ou à l'aide des patrons adaptateur/écouteur dans Java 1.1).

À ce propos, il faut remarquer que les informations sémiques sauvegardées dans le modèle sont tenues de suffisantes pour toute application qui utilise la SII. Donc les nouvelles structures ajoutées par une application ne vont servir qu'à une amélioration de la performance (complexité) de ses algorithmes ; elles restent toujours calculables à partir des informations qui se trouvent déjà dans le modèle.

Si, de cette manière, l'extension vers de nouvelles applications devient facilement implantable, le besoin d'extension du modèle statique lui-même est un cas différent et il est examiné dans la section 5.5.3.

Selon ce nouveau point de vue à travers une modélisation objet, les objectifs applicatifs sont retranscrits de la manière suivante :  

• Constituer un modèle statique persistant qui a, en plus, les fonctionnalités principales attribuées à un framework; c.-à-d. un modèle qui intègre les contraintes sur la constitution, la structuration et l'interaction des données.
• Constituer des applications qui sont principalement concernées par l'aspect dynamique de l'interaction avec l'utilisateur en laissant la communication avec le modèle à la charge de contrôleurs génériques ou spécifiques à chaque application.
• Si une application a besoin de structures de données supplémentaires pour améliorer ses performances, elle doit gérer elle-même (à travers un contrôleur spécifique) la mise à jour de ces structures de données à partir des informations qui se trouvent dans le modèle.

Ces objectifs ont guidé le processus de conception pour prendre une forme finale présentée plus bas (cf. p. et sq.).

Entre temps, nous présentons succinctement l'historique du développement applicatif. Car nous croyons que lors du cycle de vie d'un produit objet (e.g. [45]) depuis la spécification et l'analyse jusqu'à une réalisation stable, les phases de la modification et de l'évolution peuvent introduire intuitivement et justifier techniquement les prises de décision dans la conception finale. Le produit final, présenté seul, semble souvent arbitraire et son fonctionnement interne, dès qu'il dépasse un seuil de complexité, devient obscur.

C'est un peu l'impression que nous donne un formalisme mathématique, quand il est présenté dans sa version finale. Et ceci ne concerne pas son utilisation mais la compréhension des choix internes au formalisme-même. Les exemples ne peuvent aider qu'à comprendre le comment et pourquoi de son utilisation et guère de sa construction interne et sa forme actuelle^5.3.

Le projet applicatif de ce travail est inévitablement passé par une phase de réalisation prototypique pour, ensuite, être évalué et surtout évoluer vers une conception plus modulaire et plus ergonomique (i.e. utilisable). Nous trouvons alors utile de mettre l'accent sur les aspects de cette évolution qui permettra de mieux appréhender les choix finaux.

Dans le premier cycle d'évolution, nous présentons ces points de la phase d'analyse et de réalisation que nous considérons essentiels pour la démonstration de l'évolution vers la version stable.