PROPOSITION DE SPÉCIFICATION DES COMPOSANTS LOGICIELS ET DE LEUR AGRÉGATION

ÉTAT DE L’ART DU DOMAINE

Ce chapitre a pour objectif de résumer la littérature relative aux concepts et aux idées présentées dans l‟introduction. La section 1.1 explique brièvement l‟origine du paradigme objet et ses caractéristiques. Ce paradigme a montré des limitations quant au développement par la réutilisation, ainsi le composant est proposé comme l‟unité de base des systèmes complexes. Dans la section 1.2, on décrit le paradigme composant, ses différentes catégories, son utilisation et les différents types d‟agrégations auxquelles il peut participer. Les métadonnées associées au composant lui offrent une visibilité et facilitent sa recherche dans les entreprises de développement logiciel. Ce concept est étudié dans la section 1.3 avec la classification et l‟ontologie. Dans la section 1.4, on décrit le concept de la modélisation et son apport pour la représentation abstraite des composants logiciels.

Ce dernier favorise la réutilisation au niveau conceptuel et devient pratique lorsqu‟il intègre les étapes d‟un processus de développement. La section 1.5 présente de manière générale l‟ingénierie de réutilisation du logiciel. La section 1.6 traite particulièrement le volet de l‟ingénierie du logiciel par la réutilisation des composants ainsi que les processus de développement des systèmes à base de composant (section 1.7). En théorie, les communications entre les composants sont traduites sous la forme de contrats de composants. Ce concept est défini et détaillé dans la section 1.8. En pratique, un contrat de composants s‟implémente à l‟aide des techniques et des technologies d‟intégration qui sont décrites dans la section 1.9. Enfin, la conclusion de la section 1.10 résume les concepts élaborés et introduit les chapitres de développement de la thèse. L‟état de l‟art est la deuxième étape de la démarche de notre méthodologie de recherche. La figure suivante positionne le présent chapitre dans le cheminement des étapes de la méthodologie de recherche.

Le paradigme

Objet Introduit dans les années 60 dans les langages de simulation (Simula, 67), le paradigme objet était utilisé dans le domaine de l‟intelligence artificielle dans les années 80. Son apport fondamental consiste à combiner au sein d’une même structure de données, appelée classe, les opérations et les données. L‟idée centrale derrière cette alternative est de monter une modélisation fidèle du monde réel. Les analystes et les concepteurs de systèmes informatiques visent à analyser et à concevoir des objets en transposant ces derniers de la problématique du monde réel en objets ayant un ensemble d‟attributs et de responsabilités qui définissent leur comportement. De ce fait, les langages de programmation ont suivi ce paradigme, comme en témoigne l‟effervescence des langages de programmation orientés objet comme Ada, Smalltalk, Java, C++, C#, etc. Cette vague continue son émergence et son influence sur beaucoup de domaines et de disciplines (Szyperski, Gruntz, & Murer, 2002) .

Ce paradigme objet est connu par les concepts majeurs tels l’abstraction, l’encapsulation, la modularité, le polymorphisme et l’héritage (concepts introduits par le langage SmallTalk (Coad & Yourdon, 1990)). Les objets ne peuvent pas être réutilisés à grande échelle. Ils sont utiles pour le développement d‟applications, mais présentent des limitations quand il s‟agit d‟intégration entre des systèmes d‟informations ou des applications (Szyperski, Gruntz, & Murer, 2002). Les composants, souvent de taille plus grande que les objets, sont une solution plus pragmatique dans le développement des systèmes par assemblage ou par composition. Dans une vision « objet », un composant peut être vu comme un agrégat d‟objets interconnectés en vue de satisfaire un ensemble de besoins spécifiques dans un contexte particulier.

Le paradigme Composant : définition, classification et réutilisation Il existe plusieurs définitions du paradigme « Composant logiciel ». Cette section rappelle les plus utilisées et spécifie, à la fin, celle adoptée pour le reste du document. Selon (Booch, Rumbaugh, & Jacobson, 1999), un composant est une partie physique et remplaçable d‟un système qui est conforme à la réalisation d‟un ensemble d‟interfaces qu‟il fournit. Typiquement, il représente autrement l’empaquetage physique d‟éléments logiques, tels que des classes, des interfaces et des collaborations. Pour (Szyperski, Gruntz, & Murer, 2002), un composant logiciel est une unité de composition reliée à des interfaces particulières et se rattachant à un contexte de dépendances explicite. Un composant logiciel peut être déployé indépendamment et faire l’objet d‟une composition par un tiers. Pour sa part (Larman, 2002) précise qu‟un composant est indispensable, presque indépendant.

Il présente une partie remplaçable d‟un système qui accomplit des fonctionnalités claires dans le contexte d‟une architecture bien déterminée. Un composant est conforme à une implémentation physique d‟un ensemble d‟interfaces. Dans la littérature, il y a plusieurs catégories d‟associations auxquelles un composant peut participer. En effet, un composant peut contribuer à une composition, une coordination (Villalobos, 2003), une intégration (Denno, Steves, Libes, & Barkmeyer, 2003), une orchestration ou un assemblage (Renaux, Olivier, & Jean-Marc, 2004). Ces catégories prêtent souvent à confusion. Beaucoup les utilisent pour dire la même chose alors que réellement il y a une différence qui découle du contexte de leur utilisation et du type de connexion qui s‟établit entre les composants associés. Les paragraphes suivants donnent un aperçu des définitions de ces termes. Une association de composants est une mise en relation de communication entre deux composants. Cette communication met en relation directe les services fournis et ceux requis des deux composants participants. De ce fait, une agrégation de composants est une association complexe mettant en relation de composition plus de deux composants selon une logique métier et un contexte particuliers (Ivers et al., 2004). On entend par composition, une manière de structurer et de construire des applications à partir de composants logiciels. Villalobos se base sur les trois types de composants – boîte noire, boîte blanche et boîte grise – pour définir ces trois types de composition (Villalobos, 2003):

Les métadonnées, la classification et les ontologies pour le référencement Par définition, les métadonnées sont les données qui décrivent des données. On les appelle aussi des informations sur les données ou bien des informations sur des informations. En d‟autres termes, les métadonnées sont un ensemble de données qui décrivent des informations sur des ressources. Pour raffiner cette description, on peut dire que les métadonnées sont des données structurées servant à décrire une ressource (Greenberg, 2002). Ces données structurées impliquent un ordonnancement systématique des données correspondant à une spécification d‟un schéma de métadonnées. Cette spécification est une représentation officielle qui précise des règles de structuration des données en question. Pour qu‟elles soient interprétables par les machines, ces métadonnées doivent être représentées par un langage standardisé tels que XML. Ceci favorise, via des programmes informatiques spécifiques, l‟interopérabilité et la communication entre des applications réalisées avec des technologies hétérogènes.

Il est important de préciser que ces métadonnées structurées sont facilement interprétables par les machines à l‟aide des programmes spécialisés et ne le sont pas nécessairement par les humains. Une classification est une manière de catégoriser un ensemble de concepts. Cette catégorisation peut être faite sous la forme d‟une hiérarchie. Cette dernière ressemble à un arbre, elle possède une racine et des branches. Chaque branche pointe vers un point appelé noeud. La classification est aussi appelée taxonomie. En technologie de l‟information, une taxonomie est une classification des entités d‟information sous la forme de hiérarchie en correspondance avec les relations présumées des entités du monde réel qu‟elles représentent (M.C. Daconta, L.J. Obrst, & Smith, 2003).

Le rapport de stage ou le pfe est un document d’analyse, de synthèse et d’évaluation de votre apprentissage, c’est pour cela rapport gratuit propose le téléchargement des modèles gratuits de projet de fin d’étude, rapport de stage, mémoire, pfe, thèse, pour connaître la méthodologie à avoir et savoir comment construire les parties d’un projet de fin d’étude.

Table des matières

AVANT-PROPOS
REMERCIEMENTS
RÉSUMÉ
ABSTRACT
TABLE DES MATIÈRES
LISTE DES TABLEAUX
LISTE DES FIGURES
LISTE DES ABRÉVIATIONS, SIGLES ET ACRONYMES
INTRODUCTION
CHAPITRE 1 ÉTAT DE L‟ART DU DOMAINE
1.1 Le paradigme Objet
1.2 Le paradigme Composant : définition, classification et réutilisation
1.3 Les métadonnées, la classification et les ontologies pour le référencement
1.4 La modélisation logicielle
1.5 La réutilisation dans le développement logiciel à base de composants
1.6 Ingénierie du logiciel par réutilisation de composants
1.7 Les processus de développement à base de composants
1.8 Les contrats des composants
1.9 Les technologies d‟intégration des composants logiciels
1.10 Les résultats de recherche en matrice
1.11 Conclusion
CHAPITRE 2 PROPOSITION DE SPÉCIFICATION DES COMPOSANTS LOGICIELS ET DE LEUR AGRÉGATION
2.1 Les différents types de métadonnées d‟un composant logiciel
2.1.1 Spécification des métadonnées statiques
2.1.2 Spécification des métadonnées d‟affaires
2.1.3 Spécification des métadonnées des services
2.1.4 Spécification des métadonnées non fonctionnelles
2.1.5 Spécification des métadonnées des plateformes
2.2 Différentes représentations de SOCOM
2.2.1 Représentation relationnelle
2.2.2 Représentation en format d‟échange XML
2.2.3 Représentation ontologique
2.2.4 Comparaison entre les différentes représentations
2.3 Gestionnaire des composants logiciels SOCOM
2.4 Recherche des composants logiciels à l‟aide des attributs SOCOM
2.4.1 Recherche simple
2.4.2 Recherche avancée
2.4.3 Recherche par ontologie
2.5 Conclusion
CHAPITRE 3 CLASSIFICATION DES AGRÉGATIONS DES COMPOSANTS
3.1 Le besoin en attributs d‟agrégation
3.2 Spécification des métadonnées d‟agrégation
3.3 Les classes d‟agrégation des composants logiciels
3.3.1 Élément de base pour la définition des classes d‟agrégation
3.3.2 Agrégation de base : agrégation par connexion
3.3.3 Agrégation par collection
3.3.4 Agrégation par coordination
3.3.5 Agrégation par fusion
3.4 Tableau récapitulatif des caractéristiques des différentes classes d‟agrégation
3.5 Les différents patrons d‟agrégation des composants logiciels
3.5.1 Les patrons d‟agrégation par connexion
3.5.2 Les patrons d‟agrégation par collection
3.5.3 Les patrons d‟agrégation par coordination
3.5.4 Les patrons d‟agrégation par fusion
3.6 Le modèle XML d‟agrégation
3.7 Conclusion
CHAPITRE 4 PROCESSUS D‟AGRÉGATION DES COMPOSANTS LOGICIELS
4.1 Objectifs du processus SOCAP
4.2 Positionnement de SOCAP avec des processus connexes
4.3 Rôles et responsabilités des acteurs principaux
4.3.1 Architecte de composant
4.3.2 Directeur de projet
4.3.3 Intégrateur de composant
4.3.4 Développeur de composant
4.3.5 Responsable de l‟assurance qualité
4.3.6 Responsable de la gestion des configurations
4.4 Rôles et responsabilités des acteurs secondaires
4.4.1 Responsable des infrastructures
4.4.2 Responsable des bases de données
4.4.3 Responsable des réseaux
4.4.4 Responsable de la sécurité
4.5 Les principes du processus SOCAP
4.6 Les hypothèses du processus SOCAP
4.7 Modèle BPMN du processus SOCAP
4.8 Les métadonnées de l‟agrégat
4.9 Description des activités et des étapes principales du processus
4.9.1 ACT.01 – Définir le nouvel agrégat
4.9.2 ACT.02 – Référencer les composants participants
4.9.3 ACT.03 – Sélectionner les composants de l‟agrégat
4.9.4 ACT.04 – Étudier la faisabilité d‟agrégation des composants
4.9.5 ACT.05 – Analyse du rapport de faisabilité de l‟agrégation des composants
4.9.6 ACT.06 – Conception de l‟agrégat
4.9.7 Étape de développement l‟agrégat
4.9.8 Étape de configuration des environnements
4.9.9 Étape de déploiement de l‟agrégat
4.9.10 Étape de test de l‟agrégat
4.9.11 Étape de référencement du nouvel agrégat
4.10 Conclusion
CHAPITRE 5 PROCESSUS D‟ÉVALUATION DE LA FAISABILITÉ DE L‟AGRÉGATION DES COMPOSANS LOGICIELS
5.1 Importance de l‟évaluation de la faisabilité
5.2 Les règles d‟agrégation des composants logiciels
5.2.1 Règle zéro d‟agrégation : règle financière (RA-00)
5.2.2 Première règle d‟agrégation : règle d‟affaires (RA-01):
5.2.3 Deuxième règle d‟agrégation : règles des attributs non fonctionnels (RA- 02
5.2.4 Troisième règle d‟agrégation : règles des plateformes (RA-03):
5.2.5 Quatrième règle d‟agrégation : règles de l‟interopérabilité des services (RA-04):
5.2.6 Cinquième règle d‟agrégation : règle des attributs d‟agrégation (RA-05):
5.3 Cheminement des règles d‟agrégation et les états de l‟agrégat
5.4 La classification des incompatibilités des composants logiciels
5.4.1 Les incompatibilités architecturales des composants logiciels
5.4.2 Les incompatibilités sémantiques et pragmatiques des composants logiciels
5.4.3 Incompatibilités des plateformes
5.5 Processus d‟étude de la faisabilité d‟agrégation des composants logiciels
5.5.1 Modèle BPMN du processus
5.5.2 Acteurs du processus : rôles et responsabilités
5.5.3 Contraintes générales
5.5.4 Hypothèses et pré-conditions
5.5.5 Description détaillée des activités principales du sous-processus
5.6 Conclusion
CHAPITRE 6 CADRE CONCEPTUEL POUR L‟AGRÉGATION DES COMPOSANTS LOGICIELS (SOCAF – SOftware Component Aggregation Framework)
6.1 Le besoin d‟un cadre de travail
6.2 Définition et structure générale de SOCAF
6.3 Composition de SOCAF : entités conceptuelles
6.3.1 Gestionnaire des métadonnées des composants SOCOM
6.3.2 Gestionnaire du code des composants
6.3.3 Recherche des composants
6.3.4 Modélisation des composants logiciels SOCOM
6.3.5 Assistance à l‟agrégation des composants SOCOM
6.3.6 Développement des composants logiciels
6.3.7 Processus d‟agrégation des composants logiciels
6.4 Les interactions entre les entités
6.5 Exemple d‟instanciation du cadre de travail SOCAF dans un contexte réel
6.6 Conclusion
CHAPITRE 7 VALIDATION PAR L‟EXÉCUTION DU PROCESSUS SOCAP
7.1 Processus de validation du processus
7.2 Aspects communs à toutes les exécutions de SOCAP
7.3 Agrégation par coordination: « Portail-outils » de TELUS
7.3.1 Fiche SOCAM de l‟agrégat
7.3.2 Particularités de l‟exécution
7.4 Agrégation par collection: « Portail Loisir en ligne – VDM»
7.4.1 Fiche SOCAM de l‟agrégat
7.4.2 Les particularités de l‟exécution
7.5 Agrégation par fusion: « Calendrier » de la VDM
7.5.1 Fiche SOCAM de l‟agrégat
7.5.2 Particularités de l‟exécution
7.6 Agrégation par connexion: «Télépaiement de Loisir-En-Ligne – VDM »
7.6.1 Fiche SOCAM de l‟agrégat
7.6.2 Particularités de l‟exécution
7.7 Description des exécutions non réalisables
7.8 Application des mesures du modèle de validation du processus SOCAP
7.8.1 Mesure 1 : évaluation de l‟Indice de Couverture des Activités suite à l‟exécution de SOCAP, ICAS
7.8.2 Mesure 2 : évaluation de Indice de Couverture des Objectifs suite à l‟exécution de SOCAP, ICOS
7.8.3 Mesure 3 : évaluation de l‟indicateur IAS
7.9 Les défis et les limites des exécutions
7.10 Résultat et conclusion
DISCUSSION DES RÉSULTATS
CONCLUSION
RECOMMANDATIONS
ANNEXE I EXÉCUTION D‟UNE AGRÉGATION PAR COORDINATION: « Portail-outils»
ANNEXE II LES FICHES SOCOM DU COMPOSANT AGRÉGAT RÉSULTANT DE L‟AGRÉGATION PAR COORDINATION
LISTE DE RÉFÉRENCES BIBLIOGRAPHIQUES