LIMSwiki

Exemple d'une représentation UML d'un composant logiciel.

En architecture logicielle, un composant logiciel est un élément constitutif d'un logiciel destiné à être incorporé en tant que pièce détachée dans des applications. Les paquets, les bibliothèques logicielles, les exécutables, les fichiers, les bases de données ou encore des éléments de configuration (paramètres, scripts, fichiers de commandes) sont des composants logiciels[1].

Les composants logiciels sont développés par des professionnels de l'informatique en vue d'être réutilisés dans leurs propres logiciels, ou en vue d'être mis sur le marché et incorporés dans des logiciels tiers. Les composants peuvent être distribués comme pièces détachées dans le commerce sous licence propriétaire ou libre.

Typologie des logiciels

Les composants logiciels - de même que les patterns ou d'autres artefacts - peuvent être classifiés en fonction de trois axes : la granularité, l'activité et la dépendance vis-à-vis d'un domaine d'expertise particulier[2].

  • L'activité est la phase du processus logiciel (analyse, conception ou codage) où se retrouve l'artefact. Les composants produits à l'interne sont habituellement exclusivement au niveau du codage puisqu'ils représentent des objets achevés alors que les composants externes ou déjà conçus peuvent se retrouver au niveau de la conception et même de l'analyse.
  • La granularité détermine le nombre d'éléments élémentaires (classes, objets, tables) compris dans le composant ; habituellement un composant possède une faible granularité. Une collection de composants est plutôt baptisée une bibliothèque.
  • Le domaine détermine le degré de dépendance vis-à-vis d'un domaine d'expertise particulier. Les composants verticaux ou métiers encapsulent l'expertise d'un domaine particulier (finance, commerce…). Les composants horizontaux ou d'applications encapsulent l'expertise applicable à toute sorte d'applications (base de données, communication réseau, affichage…).

Il serait également possible de classifier les composants en fonction des services rendus. Il s'agit d'ailleurs de la seule typologie dans les architectures de médiation (voir architecture orientée services, architecture ARPA I3).

Composants d'extension

Un plugin ou plugiciel est un composant logiciel destiné à apporter des nouvelles fonctionnalités à un logiciel applicatif.

Un codec est un composant logiciel destiné à transformer une information numérique de et vers un certain format de données en appliquant un procédé, par exemple de compression de données.

Un widget est un composant logiciel qui anime un certain type d'élément visuel des interfaces graphiques. Exemples : bouton, zone de texte, barre de défilement.

Un pilote (anglais driver) est un composant logiciel qui assure l'utilisation d'une pièce de matériel informatique.

Composant en tant que bibliothèque

Une bibliothèque logicielle est un ensemble de composants en rapport avec un sujet particulier et réunis dans le même logiciel. Exemples : calcul mathématique, manipulation de fichiers, compression de données.

Un moteur de calcul est une bibliothèque logicielle ou un composant unique qui effectue un travail de manière automatique. Exemples : interpréteur, moteur de recherche, moteur de jeu, moteur de rendu, moteur de base de données embarqué.

Un framework (cadriciel) est une bibliothèque logicielle destinée à donner à un logiciel une architecture. Le logiciel est alors construit sur le squelette créé par le cadriciel.

Composant de données

Une base de données est une collection de données utilisée par un système informatique.

Une ontologie est un composant logiciel permettant de définir la sémantique d'un système informatique (voir architecture de médiation).

Le couplage technologique

La notion de couplage concerne les dépendances des éléments logiciels les uns avec les autres. Les diagrammes de composants permettent de visualiser ce couplage (dépendance entre composants). Au niveau technologique, il existe plusieurs façons de réaliser un couplage ; la complexité de celui-ci étant croissante en fonction de la disparité technologique des composants.

Du point de vue du programmeur, le couplage entre modules est habituellement transparent et se fait par une interface de programmation (abrégé API). Puisqu'ils sont destinés à être utilisés par d'autres logiciels, les modules ont tous une interface de programmation.

Un module de code source d'un langage de programmation quelconque contenant des classes, objets et/ou fonctions peut-être réutilisé tel quel par un autre module écrit dans le même langage.

Une version compilée de ce code source peut générer une bibliothèque (dynamique ou statique) de code natif pouvant être utilisée par n'importe quel langage de programmation générant du code natif pour la même plate-forme.

  • Une bibliothèque est dite statique quand celle-ci est liée au moment de la construction du nouveau composant, typiquement à la suite de la compilation. Le nouveau composant contient alors toutes ses dépendances (composants dont il a besoin) incorporées. C'est par exemple le cas des logiciels écrits en Rust qui lient statiquement (par défaut) leurs dépendances dont la bibliothèque standard.
  • Une bibliothèque est dite dynamique quand celle-ci est liée au moment de l'utilisation d'un composant. Le moteur d'exécution (anglais runtime) recherche alors toutes les dépendances (composants nécessaires) à son fonctionnement. Comme leur nom l'indique, les Dynamic Link Library du système d'exploitation Windows sont utilisées en liaison dynamique.
  • La liaison à un composant est dite tardive (late binding) quand celle-ci est réalisée après le démarrage du programme, au moment où le composant en question est effectivement utilisé, par exemple lorsque l'usager lance une opération qui nécessite le composant en question. Il s'agit d'une liaison dynamique contrôlée par le programme lui-même.

La création de proxy et l'utilisation du marshalling permettent le couplage dynamique de composants usant de codes machine différents et/ou se trouvant distribués sur différentes plates-formes en utilisant un middleware comme DCOM, de Microsoft, JavaBeans de Sun Microsystems et CORBA de OMG.

Habituellement, un module se couple à une ou plusieurs bases de données en utilisant un client multibases.

Bibliographie

(en) Component software: beyond object-oriented programming

Notes et références

  1. Pierre-Alain Muller, Nathalie Gaertner, Modélisation objet avec UML, Eyrolles, deuxième édition 2000, p.231 (les composants)
  2. Pierre-Alain Muller, Nathalie Gaertner, Modélisation objet avec UML, Eyrolles, deuxième édition 2000, p.87 (utilisation conjointe de patterns et de frameworks)