Modèle de l'arche

Le modèle de l'arche stipule qu'une application interactive est constitué des cinq parties suivantes[1]:

• le noyau fonctionnel, qui contient les données et les traitements manipulés par le programme. Exemples : le texte et sa mise en page dans un traitement de texte, les données de plan de vol dans un logiciel de contrôle aérien.

• l'adaptateur du noyau fonctionnel, une couche qui assure la médiation entre le noyau fonctionnel et la partie suivante, le contrôleur de dialogue. Le but est de gérer les divergences entre le noyau fonctionnel et l'interface : différences de typage, voire différences de structure.

• le contrôleur de dialogue, qui gère le séquencement des tâches. Il reçoit des commandes complètes sans savoir comment elles ont été produites. Il choisit quelles sont les données du noyau fonctionnel qui doivent être présentées à un moment donné.

• la présentation logique, qui assure la médiation entre le contrôleur de dialogue et la partie suivante, la présentation physique.

• la présentation physique, qui inclut les périphériques d'interaction et les composants logiciels d'interaction, par exemple la souris et les boîtes de dialogue.

Les parties "adaptateur de noyau fonctionnel" et "présentation logique" ont pour rôle d'assurer l'indépendance entre les autres parties. Elles correspondent aux lignes de programme qui doivent être écrites pour réutiliser un noyau fonctionnel avec une nouvelle interface, ou porter un logiciel interactif sur un nouveau système d'exploitation.

Le modèle Arch-Slinky est un raffinement du modèle de l'arche. Par rapport au modèle de l'arche, Slinky précise que la taille des parties est variable et peut être nulle en fonction des situations.

Tout comme le modèle de Seeheim, le modèle de l'arche est un patron :

• abstrait : il ne précise pas comment réaliser les différentes parties et leurs interconnexions en utilisant les constructions disponibles dans les langages de programmation.

• de haut niveau : il s'applique à l'analyse des logiciels à un grain macroscopique, au niveau du module, de la bibliothèque ou du processus. Il existe des modèles abstraits de plus bas niveau, destinés à l'analyse à grain microscopique, au niveau de la fonction ou de la classe (voir MVC et PAC).