- Programmation orientée composant
-
La programmation orientée composant (POC) consiste à utiliser une approche modulaire au niveau de l'architecture d'un projet informatique, ce qui permet d'assurer au logiciel une meilleure lisibilité et une meilleure maintenance. Les développeurs, au lieu de créer un exécutable monolithique, se servent de briques réutilisables.
La POC n'est pas sans similitudes avec la POO, puisqu'elle revient à utiliser une approche objet, non pas au sein du code, mais au niveau de l'architecture générale du logiciel.
La POC est particulièrement pratique pour le travail en équipe et permet d'industrialiser la création de logiciels.
Sommaire
Le composant, base de la POC
Qu'est-ce qu'un composant ?
Lorsque l'on parle de composants, il s'agit de simples fichiers, contenant généralement du code compilé. Sous les systèmes de type Unix, par exemple, les composants se présentent sous la forme de fichiers portant l'extension .so (shared object). Sous les systèmes de type Microsoft Windows, il s'agit des fameuses dll (dynamic library link). On parle également de modules, de bibliothèques, ou de librairies, par abus de traduction (library étant un faux ami et signifiant bibliothèque)
Il est possible de créer des composants avec la grande majorité des langages. Toutefois, dans certains cas, notamment pour les langages interprétés ou semi-compilés il n'est pas possible de créer des composants « classiques ». Par exemple, en python, les composants sont des simples fichiers contenant du code (.py), tandis qu'en java, il est possible de créer des bibliothèques de classes (.jar). Ainsi, seul un programme écrit en java pourra utiliser comme composant un fichier .jar.
Un composant regroupe un certain nombre de fonctionnalités qui peuvent être appelées depuis un programme externe, ou client. Comme le composant ne contient que du code compilé, il n'est a priori pas possible de savoir de quelle manière elles sont implémentées, à moins de disposer du code source. De plus, pour pouvoir être utilisé, le composant doit fournir une interface, c'est-à-dire un ensemble de fonctions lui permettant de communiquer avec le programme client. Dans le cas où le code source n'est pas disponible, les spécifications détaillées de ces fonctions doivent être fournies avec la documentation.
Un composant est censé fournir un service bien précis. Les fonctionnalités qu'il encapsule doivent être en rapport et cohérentes entre elles. On verrait mal l'intérêt d'un composant regroupant les tâches de gestion d'impression et de compression de fichiers, par exemple.
Enfin, un composant doit être réutilisable, c’est-à-dire qu'il ne doit pas simplement servir dans le cadre du projet durant lequel il a été développé. Cet aspect n'est possible qu'à la condition qu'il possède un comportement suffisamment général. Trouver un compromis entre la spécialisation du composant pour optimiser son utilisation dans le cadre du projet actuel, et sa généralisation en vue de sa réutilisation est souvent un casse-tête lors de la phase de conception du projet.
Structure d'un composant
Comme le composant n'est utilisable qu'une fois compilé, la méthode d'implémentation importe peu. Il est possible d'utiliser une approche objet ou procédurale. Il convient d'éviter une confusion courante : la POC et la POO sont des choses différentes. Utiliser la POO pour développer un composant est facultatif. En fait, l'implémentation du composant n'a aucune influence sur les programmes clients, du moment que les signatures de l'interface ne changent pas.
Le code d'un composant peut en effet être séparé en deux parties. Tout d'abord, les méthodes et données internes. Un composant peut implémenter des fonctions qu'il utilise « pour son compte personnel », et qui ne sont pas accessibles de l'extérieur. On parle de méthodes « privées ». Ensuite, le composant, pour pouvoir être utilisé, doit fournir un moyen de communication avec les programmes clients. Certaines fonctions sont donc accessibles de l'extérieur, et dévolues à être appelées par ces programmes. On parle de méthodes « publiques », ou d'« interface ».
Comment fonctionnent les composants ?
Parler des différentes phases de compilation, lien à l'exécution, etc.
Exemples de programmation de composants dans différents langages
Montrer des exemples de codes et d'instructions de compilation qui permettent d'utiliser les composants
La POC dans la gestion de projet informatique
Les avantages à utiliser la POC
Les avantages à utiliser une approche POC pour conduire un projet sont multiples :
- spécialisation : L'équipe de développement peut-être divisée en sous-groupes, chacun se spécialisant dans le développement d'un composant
- sous traitance : Le développement d'un composant peut-être externalisé, à condition d'en avoir bien réalisé les spécifications au préalable
- facilité de mise à jour : La modification d'un composant ne nécessite pas la recompilation du projet complet
- facilité de livraison/déploiement : Dans le cas d'une mise à jour, d'un correctif de sécurité, ... alors que le logiciel à déjà été livré au client, 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é
- 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
- 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é souvent
Et les inconvénients
Bien que l'utilisation de la POC soit réellement appréciable dans la conduite d'un projet de développement, elle n'est pas sans imposer quelques contraintes importantes.
Tout d'abord, la POC est une méthode dont le bénéfice se voit surtout sur le long terme. En effet, lorsque l'on parle de réutilisation, de facilité de déploiement, c'est que le développement est sinon achevé, du moins bien entamé. Mais factoriser un logiciel en composants nécessite un important travail d'analyse. La rédaction des signatures des méthodes devra être particulièrement soignée, car modifier une signature nécessitera de retravailler toutes les portions de codes du projet qui font appel au composant, et l'on perdrait alors les bénéfices de l'indépendance des briques logicielles.
En un mot, si la POC industrialise le développement, la phase de conception du logiciel prendra un rôle encore plus important.
Le fait de ne pas connaître l'implémentation d'un composant (à moins d'avoir accès aux sources), peut également gêner certains chefs de projets qui veulent garder un contrôle total sur leur logiciel.
Sources externes
Francophones
Anglophones
- Mass Produced Software Components by M. Douglas McIlroy
- NATO Science Committee Software Engineering Conference in Garmisch - rapport (PDF)
- Planification de la révolution de l'industrie logicielle Histoire comparé de la fabrication face au logiciel.
- La notion d'indépendance pour l'orienté-composant.
- Démonstration de faisabilité par M. COX d'un mécanisme fondé sur l'utilisation pour l'inventivité des producteurs de composants.
- Liste compréhensive de Systèmes à Composants
- Article "Pourquoi la réutilisation logicielle a échoué et comment faire pour que ça fonctionne pour vous" par en:Douglas C. Schmidt
- Article "Piecing together the component puzzle for greater gains"
- New proposals to explore the Component properties: (i) Reuse and (ii) Loose coupling
- http://www.smb.uklinux.net/reusability/
- Dynamically Self Configuring Automotive System
Wikimedia Foundation. 2010.
