Avantages et inconvénient de la programmation orientée composants

Essentiellement utilisée par les entreprises de création de logiciels, la programmation orientée composants compte, parmi ses avantages communément admis :

1. La centralisation des compétences : L’équipe de développement peut-être divisée en sous-groupes, chacun se spécialisant dans le développement d’un composant,

2. La sous-traitance : Le développement d’un composant peut-être externalisé, à condition d’en avoir bien réalisé les spécifications au préalable,

2.2. LA PROGRAMMATION ORIENTÉE COMPOSANTS 45 3. Facilité de mise à jour : La modification d’un composant ne nécessite pas la recompilation du

projet complet, voir pas de recompilation du tout,

4. Facilité de livraison/déploiement : Dans le cas d’une mise à jour, ou d’un correctif, la livraison en est facilitée, puisqu’il n’y a pas besoin de re-livrer l’intégralité du projet, mais seulement le composant modifié,

5. Choix des langages de développement : Il est possible, dans la plupart des cas, de développer les différents composants du logiciel dans des langages de programmation différents. Ainsi, un composant nécessitant une fonctionnalité particulière pourra profiter de la puissance d’un langage dans un domaine particulier, sans que cela n’influe le développement de l’ensemble du projet,

6. Productivité : La réutilisabilité d’un composant permet un gain de productivité non négligeable car elle diminue le temps de développement, d’autant plus que le composant est réutilisé sou-vent.

L’un des inconvénients essentiels de ce type de programmation est que le découpage fonctionnel d’une application en divers composants doit être mené de manière très rigoureuse, tout en pensant au fait que le composant doit être réutilisable, c’est à dire penser également à son utilisation future. Ceci peut amener un système développé en employant la méthode de programmation orientée composants à consommer sensiblement plus de ressources qu’une application programmée avec une méthode traditionnelle. En effet, le système de communication entre les composants est plus coûteux en temps de calcul qu’un simple appel de fonction.

2.2.4.2 Intérêt pour le monde académique

Si la programmation orientée composant a gagné des secteurs entiers de l’industrie du logiciel, le monde académique n’est pas en reste par rapport à cette technique. A titre d’exemple, nous pouvons citer quatre projets qui s’appuient sur une architecture à base de composants.

OSCAR

OSCAR [Blum, 2001] (Operating System for the Control of Autonomous Robots) est une archi-tecture développée par l’université de Munich, basée sur des composants pour la robotique mobile. Ce domaine de recherche présente quelques problématiques communes avec la réalité augmentée, notamment le problème de la localisation. Ainsi, les raisons avancées par l’auteur pour justifier son approche basée composants sont les suivantes :

– Les mesures acquises par les capteurs se font en parallèle et nécessitent plusieurs chaînes de traitement concurrentes,

– La modularité aide au développement en équipe et facilite les tests,

– L’utilisation des composants apporte robustesse, flexibilité et reconfigurabilité au système. L’auteur développe ensuite un système pour la robotique mobile basé sur CORBA, ce qui lui permet de décentraliser certains calculs sur des machines distribuées.

ORCA

Plus récemment, toujours en robotique mobile, le système ORCA [Brooks et al., 2005] a été dé-veloppé par l’université de Sydney. Les motivations derrière la création de ce système, basé ici aussi sur CORBA sont les suivantes :

1. La complexité inhérente de la robotique mobile. Celle-ci est due à l’interaction de capteurs hétérogènes, avec de nombreux algorithmes (un problème similaire jusque là à celui de la réalité augmentée mobile) et avec un certain nombre d’actionneurs.

2. Un besoin de flexibilité. Un système doit être suffisamment flexible pour pouvoir mener des expérimentations sur des algorithmes de fonctionnalités équivalentes sans que ceci ait des ré-percussions sur l’ensemble du système.

3. Un environnement distribué. Ceci pour pouvoir contrôler les robots à distance pendant les phases d’expérimentation.

4. L’hétérogénéité des plate-formes et du matériel informatique. Ceci est un problème récurrent en robotique mobile.

Par la suite, chaque composant de ce système est supposé être un processus autonome qui va inter-agir avec un autre ensemble de processus. Fait intéressant, la connectivité de chacun des composants est assurée par l’interprétation d’un fichier XML (eXtensible Markup Language) qui dresse la liste des connections à établir, fournissant ainsi une première couche d’abstraction par rapport à l’assemblage des composants au lieu de l’utilisation de “glu logique”.

DWARF

Nous avons déjà présenté précédemment le projet DWARF (cf section 2.1.4 page 37) mais nous allons néanmoins nous étendre sur les raisons du choix de la programmation orientée composants dans cette solution. Elle est justifiée par les concepteurs du système [Bauer et al., 2001] de la manière suivante : chaque démonstrateur de réalité augmentée développé jusqu’à l’époque de la création de leur système était centré sur une application précise, ce qui en faisait un système monolithique difficile à réemployer dans d’autres applications.

Toutefois ces différentes applications emploient les mêmes types d’algorithmes et effectuent des tâches très similaires. Elles ont en commun certains schémas de conception (appelés aussi “design patterns” ) qui posent dans les grandes lignes les architectures de ces applications. Ceci veut dire que si ces systèmes avaient été développés de manière générique et modulaire, ces derniers auraient pu être réemployés dans d’autre systèmes de réalité augmentée à moindre coût en termes d’effort et de temps de développement. Ceci se traduit par un temps plus grand consacré à la recherche de nouveaux algorithmes et de nouveaux concepts puisqu’un temps moindre est consacré au développement des prototypes et des démonstrateurs de ces technologies.

La conséquence directe de cette conclusion a débouché sur le développement du système DWARF qui est orienté composant. Par la suite, les auteurs se sont attaché à identifier ces schémas de concep-tion [MacWilliams et al., 2004] communs aux applicaconcep-tions de réalité augmentée afin de dégager les composants communs aux systèmes de réalité augmentée.

AMIRE

Ce dernier système fut également sommairement présenté précédemment (cf section 2.1.5 page 37). Le choix de la programmation orientée composants a été réalisé ici également pour des raisons de réutilisation du code déjà développé dans d’autres applications de réalité augmentée.

L’autre raison est liée aux design patterns évoqué à propos de DWARF : les concepteurs du projet ont jugé bon d’assister le concepteur d’une application de réalité augmentée via une interface gra-phique de création des applications de réalité mixée. C’est pourquoi, un squelette d’application est fourni sur lequel l’utilisateur greffe les composants qui vont assurer le bon fonctionnement du sys-tème. Ceci permet, à une personne qui n’est pas experte dans le domaine de la réalité augmentée, de

2.3. ÉBAUCHE D’UNE PREMIÈRE ARCHITECTURE 47