1 Abstraction du matériel

Les requis d’un logiciel sont habituellement établis par une personne ou un ensemble de personnes. Le requérant exprime un besoin que doit rencontrer la solution logicielle.

L’ensemble des services n’est typiquement pas implanté dans une entité logicielle monolithique, mais dispersé en plusieurs composants logiques assemblés de façon à offrir la totalité des services à un client. Ce client peut être autant une personne qu’un processus de la solution.

Une solution logicielle répartie repose sur un ensemble d’ordinateurs qui communiquent ensemble à travers un réseau informatique afin d’atteindre un même objectif [6], contrairement à une solution logicielle monolithique où la solution repose sur un seul ordinateur. Dans la même optique, la fédération de processus sur un même ordinateur est aussi un moyen de répartir une solution afin d’utiliser des ressources physiques qui lui sont propres. Une solution logicielle reste répartie tant que des ressources matérielles différentes sont utilisées par des composants logiques de la solution.

Dans le cas d’une solution monolithique, l’interface publique est reliée au seul composant logique de la solution logicielle. Dans le cadre de solutions réparties, l’interface se divise en plusieurs composants logiques qui communiquent entre eux. Il peut y avoir plusieurs interfaces publiques, et chacune d’elles est reliée à un des composants logiques de la solution.

Que la répartition d’une solution soit effectuée sur le même ordinateur ou pas, elle requiert des relations entre les composants logiques de la solution, habituellement par des liens de communication. Souvent, ces liens de communication sont implémentés par des liens de communication physiques. Le matériel utilisé pour implémenter ces liens de communication physiques fait partie d’un environnement de déploiement physique de la solution logicielle. Dans le cadre d'une solution logicielle répartie, il n’y a pas de garantie que la répartition soit identique dans tous les environnements de déploiement. Tant que des liens de communication logiques sont disponibles, les différents composants logiques peuvent être déployés de diverses façons, dans la mesure où l’implémentation physique d’un composant logique respecte des caractéristiques qui lui sont propres. Il faut donc mettre en relief ces caractéristiques, afin de fixer la portée de ce qui peut être contrôlé lors de la conception de la solution.

Certains modèles architecturaux délimitent la granularité de l’architecture de la solution logicielle en trois couches d’abstraction principales : conceptuelle, logique et physique [5]. La couche conceptuelle décrit les principales interactions entre le client et la solution logicielle, la couche logique décrit les services devant être développés pour répondre au besoin, et la couche physique décrit l’implémentation réelle des services de la solution.

Des liens permettent l’interaction entre les composants de la couche logique. Ces composants et ces liens sont ensuite détaillés dans la couche physique de l’architecture. Lorsqu’ils ne sont pas connus à l’avance, le modèle logique peut être déployé par de multiples modèles physiques. Un même composant logique peut dépendre de plusieurs composants physiques, selon le modèle utilisé.

Par contre, la diversité des composants physiques pouvant être utilisés ont des caractéristiques communes, afin de pouvoir répondre aux requis d’un composant logique. L’abstraction de ces caractéristiques spécifiques permet de diminuer le couplage entre le matériel et le logiciel. L’abstraction de ces caractéristiques permet aussi de pallier le nombre illimité d’environnements de déploiement formant des groupes de composants ayant des caractéristiques précises.

Ces regroupements constituent des abstractions du matériel qui permettent d’insérer une couche de virtualisation entre les couches d’abstraction logique et physique. Cette couche de virtualisation définit les dépendances entre un composant logique et les composants physiques, ainsi que les caractéristiques de ces dépendances.