Les nœuds vides dans la notation du triplet

Un modèle de composants 

Dans le cadre de sa thèse de doctorat, Mme Sangaré [Sangaré] Assistante chercheur à l’université Gaston Berger de Saint-louis, a proposé un modèle décrivant les composants. Toute instance d’un composant peut ainsi être représentée par une instance du modèle. Le modèle proposé est représenté à l’aide d’un diagramme de classe UML [Rumbaugh et al.]. Ce modèle de composant participe au processus de recherche et d’extraction de connaissance dans le contexte du projet PSRep (Pau Software Repository) [PSRep]. Le projet PSRep a été initié à l’université de PAU lors d’une convention de recherche pour le développement d’un catalogue et d’un browser de composants logiciels pour l’Institut Français du pétrole (IFP).
Ce projet a pour objectif le développement d’un système de gestion de bibliothèques de code source pour la réutilisation de logiciels. Dans cette partie nous définissons d’abord la notion de composant et présentons l’architecture de base du système de gestion de composants développé dans le contexte du projet PSRep. Ensuite nous donnons les concepts élémentaires nécessaires à la compréhension d’un diagramme de classe UML avant de présenter et d’expliquer le modèle proposé par Mme Sangaré.

Notion de composant logiciel

« Un composant logiciel est une unité de composition spécifiant, par contrat, ses interfaces et ses dépendances explicites aux contextes ».[ Szyperski & Pfister, 1996]. Un composant est une «boite noire», une «brique logicielle », qui accepte une valeur d’entrée connue et renvoie une valeur de sortie également connue. L’utilisation de composants facilite grandement le développement d’application grâce à la réutilisation des services qu’ils implémentent. En effet, au lieu de développer un code personnalisé pour calculer un amortissement, il est plus facile d’appeler par exemple une fonction financière prédéfinie permettant de réaliser cette tache. Si cette possibilité de réutilisation était déjà disponible avec l’approche modulaire et plus tard avec l’approche objet, le « paradigme composant » a permis de résoudre des problèmes inhérents à ces deux premières approches [Marvie et Pellegrini, 2002]. L’ingénierie de conception d’applications basée sur les composants CCBE (Component Based Software Engineering), si elle facilite la réutilisation de code, pose le problème de la recherche de composants et de leur validation (respect des exigences fonctionnelles, matérielles et logicielles du composant trouvé). La composition de composants en vue de la réalisation d’applications personnalisées demeure néanmoins un mécanisme pouvant faciliter le développement d’applications.
Il existe différentes sortes de composant selon leur niveau de transparence ou d’ouverture (les informations disponibles) :
· Composants « boîte blanche »: Elles sont fournies avec le code source et peuvent ainsi être modifiées avant leur utilisation.
· Composants « boîte noire»: Elles sont disponibles en code binaire ou en code compilé.
Contrairement aux « boîtes blanches », elles ne peuvent pas être modifiées et leurs services ne sont accessibles qu’au moyen de leurs interfaces publiques.
· Composants « boîte grise » ou « en verre »: elles possèdent les caractéristiques des deux types de composants. En effet un sous ensemble de ce type de composants est fourni en code source permettant ainsi son adaptation avant son intégration. Néanmoins, à la différence des composants « boîte blanche » elles disposent d’une partie fournie uniquement en code compilé ou binaire.
L’architecture de base du système repose sur une base d’infos-composants représentés en XML. Ces infos-composants sont obtenus au moyen de deux outils[Brou] :
§ Un outil d’extraction de méta-données permettant d’extraire de manière automatique les informations sur les composants à partir de leur code source. Le logiciel Doxygen[Doxy] est utilisé pour réaliser cette extraction. Doxygen est un logiciel libre qui permet de générer en HTML (ou XML) la documentation sur les composants (C/C++, Java) à partir de leur code source.
§ Un générateur d’infos-composants qui transforme en XML, selon une DTD de description des infos-composants, les informations obtenues au moyen de l’outil d’extraction de méta-données.
Dans ce mémoire nous nous sommes intéressés à la création de l’ontologie de description des composants et au développement du module d’interrogation sémantique. Le module d’interrogation qui offre un processus de recherche et de navigation sémantique à partir d’unnavigateur Web est présenté dans la partie II.

UML 

Dans les années 70, le succès des langages orientés objet a entraîné la naissance d’une multitude de méthodes (plus de cinquante) de modélisation objet pour aider le concepteur dans la phase d’analyse. Même si l’objectif poursuivi est identique ces méthodes se sont livrées à une véritable « method war » plongeant les utilisateurs dans une certaine confusion.
Les concepts utilisés et les domaines pris en charges étaient différents et aucune méthode n’était assez robuste et assez complète pour satisfaire à elle seule. C’est dans ce contexte qu’apparurent entre autres dans les années 90 les méthodes Booch de Grady Booch, OMT (Object Modeling Technique) de James Rumbaugh et fusion de Jacobson. Ces méthodes innovent en incorporant un ensemble de techniques issues d’autres méthodes. En 1994 Booch et Rumbaugh commencent la fusion de leur méthode qui aboutit à la version 0.8 de Unified Method. A la fin de l’année 1995 Jacobson rejoint les deux compères dans Rational et participe à la fusion avec OOSE (Object Oriented Software engineering). Leur effort combiné donne naissance à UML 0.9 (Unified Modeling Language)2 et UML 0.91 en juin et octobre.
Grâce aux suggestions de la communauté après cette première version, Rational aidé par ses partenaires regroupé au sein du consortium UML partner travaille à élaborer une version 1.0 de UML. Cette collaboration permet de définir le langage de modélisation UML soumis à l’OMG 3   Object Management Group) en janvier 1997. La version 1.1 clarifie la sémantique du 1.0 et incorpore la contribution des nouveaux partenaires. UML a beaucoup évolué depuis et est actuellement à sa version 2.0.
UML est basé sur une architecture à quatre couches avec une couche méta méta-modèle, une couche métamodèle, une couche modèle et une couche objets utilisateurs. Dans notre étude nous allons nous intéresser uniquement à la couche modèle. La modélisation consiste à créer une représentation simplifiée d’un problème : le modèle. Un modèle permet de représenter les aspects importants du système à modéliser. Pour définir et visualiser un modèle, UML utilise les diagrammes. Un diagramme UML est une représentation graphique d’un aspect précis du modèle. Chaque type de diagramme possède une structure normalisée et véhicule la même sémantique. Ensemble les diagrammes constituent le modèle UML global et représentent une vue complète des aspects statiques et dynamiques du système à modéliser. Le modèle UML est composé de neuf diagrammes dans sa version 1.1 et de treize diagrammes dans sa version 2.0. Nous allons nous limiter au modèle de classe et plus précisément aux diagrammes de classes et d’objets qui ont été utilisés pour la représentation du modèle de composants.

Diagrammes de classes et d’objets 

Un diagramme de classe montre la structure statique du modèle, en particulier, les éléments qui existent, leur structure interne et leur relation avec d’autres éléments. Il ne gère pas l’évolution de l’aspect temporel. Il est représenté par un graphe composé de classes reliées par un ensemble d’associations.

Quelques définitions 

· Classe et objet: une classe est la description abstraite d’un ensemble d’objet partageant les mêmes attributs, opérations, relations et sémantique. La notion d’objet est identique à celle relative à la programmation objet. Un objet est défini comme une entité abstraite ou concrète possédant une identité et encapsulant un état et un comportement. Un objet est une instanceou occurrence d’une classe.
· Association : il permet de définir une relation sémantique durable entre des classes.
Les instances d’une association sont un ensemble de tuples reliant des instances de classes (ie. des objets). Une association est composée de deux extrémités. Chaque extrémité reliée à une classe définit un ensemble de propriété qui doivent être remplies pour que la relation soit valide. Une extrémité d’association peut être agrégée ou non, changeable, ordonnée, navigable. Elle peut disposer d’une multiplicité et d’un nom (rôle). Une extrémité agrégée exprime une relation de contenance. Elle signifie « contient », « est composé de ». Une composition est une agrégation forte impliquant que :
o Un élément ne peut appartenir qu’à un seul agrégat composite.
o La destruction de l’agrégat composite entraîne la destruction de tous ces éléments.
· Multiplicité : Une multiplicité est définie par un ensemble non vide d’entiers non négatifs. L’ensemble {0} n’est cependant pas valide. Elle spécifie le nombre d’instances d’une classe pouvant être associé via une relation à une instance de la classe opposée. · Classe d’association : c’est une association qui est également une classe. Il permet non seulement de relier un ensemble de classes mais aussi de définir un ensemble d’éléments appartenant à la relation elle-même.
· Attributs et opérations: les attributs représentent les propriétés d’une classe. Il spécifie « l’intervalle » des valeurs permises pour chacune des propriétés grâce à son type. Une opération représente un élément de comportement (un service) contenu dans une classe. Elle dispose d’uns signature qui décrit la liste et le type de ses paramètres et éventuellement son type de retour.
Un diagramme de classe utilise également des interfaces, des packages et même des instances comme des objets et des liens. Notons que lorsqu’il ne contient que des objets il est assimilé à un diagramme d’objet. Un diagramme d’objet montre des instances compatibles avec un diagramme de classe particulier. Il spécifie l’état du système à un instant donné.

Description du modèle de composant

Le modèle décrit les composants « boîte noire » qui sont les composants les plus génériques.
En effet avec un tel modèle et en rendant facultatif les attributs liés au code source il est possible de modéliser les trois types de composants. Dans ce modèle un composant est décrit d’abord par son nom et son langage d’implémentation et est considéré comme disposant de deux parties : une partie générique et une partie spécifique.

La partie générique 

Elle englobe l’ensemble des propriétés du composant qui permettent de le décrire en faisant abstraction d’une quelconque implémentation ou plate-forme d’exécution. La partie générique dispose d’une propriété description au format texte et est décomposée en deux parties :
· Source : elle permet d’identifier la provenance du composant. Elle est décrite par un nom et dispose d’une propriété version (dernière version du composant). Pour une source donnée, on recense également ses auteurs et les différents chemins (URI) où on peut les trouver.
· Domaine : c’est une sous partie optionnelle de la partie générique. Elle permet de recenser la liste des composants qui traitent le même domaine.