Nancy, décembre 2002 page 1 Assises du GDR I3 Composants dans l'Ingénierie des SI Concepts clés et techniques de réutilisation Franck Barbier, LIUPPA Corine Cauvet, LSIS Mourad Oussalah, IRIN Dominique Rieu, LSR-IMAG Sondes Bennasri, Carine Souveyet, CRI, Paris 1

Nancy, décembre 2002 page 2 Plan * Introduction sur la réutilisation * Cadre de référence pour la comparaison des composants * Les types de composants pour les SI ( métiers, architecturaux, patrons ) * Types de démarche : Pour et Par réutilisation * Synthèse sur les démarches les plus appliquées * Conclusion

Nancy, décembre 2002 page 3 « Il n ’y a qu ’une méthode pour inventer, qui est d’imiter. Il n ’y a qu’une méthode pour bien penser, qui est de continuer quelque pensée ancienne et éprouvée ». Alain Réutilisation Une évolution « naturelle » du métier - réduire les coûts et les délais de conception, d’implantation - et de maintenance si la réutilisation s’allie à la traçabilité Conséquences sur les produits Plus rapides à développer, Plus faciles à maintenir, Certainement meilleurs, Moins originaux.

Nancy, décembre 2002 page 4 Réutilisation dans l’ingénierie logicielle adaptation de J-M. Nerson, CACM 92 Spécifications Informelles Modèle Descriptif & Normatif Informatisable Modèle Effectif Informatisé Logiciel Expression des besoins Analyse (abstraction du monde réel) Conception (solution technique) Implantation (solution opérationnelle) COMPOSANTS

Nancy, décembre 2002 page 5 Réutilisation dans l’ingénierie logicielle Spécifications Informelles Modèle Descriptif & Normatif Informatisable Modèle Effectif Informatisé Logiciel Expression des besoins Analyse (abstraction du monde réel) Conception (solution technique) Implantation (solution opérationnelle) Patrons d’analyse Modèles de domaine Composants métiers conceptuels ERP, Frameworks Patrons d’architecture Patrons de conception Composants métiers logiciels Bibliothèques de classes

Nancy, décembre 2002 page 6 Un composant réutilisable : - traite un problème récurrent de l’ingénierie des SI - capitalise un fragment de produit ou de processus - offre une solution conceptuelle et/ou logicielle testée, acceptée et adaptable Réutilisation dans l’ingénierie du logiciel èNécessité de les classifier, les documenter, les organiser, les composer… èNécessité de démarches centrées réutilisation. Une très grande variété de composants réutilisables La réutilisation ne doit plus être limitée aux produits logiciels

Nancy, décembre 2002 page 7 Plan * Introduction sur la réutilisation * Cadre de référence pour la comparaison des composants * Les types de composants pour les SI ( métiers, architecturaux, patrons ) * Types de démarche : Pour et Par réutilisation * Synthèse sur les démarches les plus appliquées * Conclusion

Nancy, décembre 2002 page 8 Critères de caractérisation des composants * type de connaissance : produit ou processus, * couverture : générale (horizontale), métier (verticale), entreprise * portée : étapes d ’ingénierie, * nature de la solution : logicielle ou conceptuelle, * technique de réutilisation : spécialisation, composition, instanciation, duplication… * ouverture : boîte noire, blanche ou en verre, * granularité : taille du composant en nombre de classes, de modules,…

Nancy, décembre 2002 page 9 Plan * Introduction sur la réutilisation * Cadre de référence pour la comparaison des composants * Les types de composants pour les SI ( métiers, architecturaux, patrons ) * Types de démarche : Pour et Par réutilisation * Synthèse sur les démarches les plus appliquées * Conclusion

Nancy, décembre 2002 page 10 Critères de caractérisation : application aux bibliothèques logicielles Type des connaissances Couverture Portée Nature de la solution Tech. de réutilisation Ouverture Granularité Spécialisation et Instanciation Classe de bibliothèques Logicielle Boîte en verre Très faible Produit Implantation Horizontale

Nancy, décembre 2002 page 11 Critères de caractérisation : application aux aux composants métiers Type des connaissances Couverture Portée Nature de la solution Tech. de réutilisation Ouverture Granularité Spécialisation et Instanciation Classe de bibliothèques Conceptuelle Boîte blanche variable Produit Analyse Verticale Plusieurs définitions Un composant métier est un composant logiciel: une entité encapsulée une entité autonome de déploiement différence avec un composant logiciel spécifique à un domaine d’application c-à-d réutilisable au sein du même domaine d’application Problème lors de l’intégration des composants Interopérabilité sémantique le demandeur et le fournisseur ont la même sémantique des services et des données échangées

Nancy, décembre 2002 page 12 Type des connaissances Couverture Portée Nature de la solution Tech. de réutilisation Ouverture Granularité Patron Conceptuelle Imitation puis Intégration Boîte blanche Faible Critères de caractérisation : application aux patrons « un patron décrit à la fois un problème qui se produit très fréquemment dans votre environnement et l’architecture de la solution à ce problème de telle façon que vous puissiez utiliser cette solution des milliers de fois sans jamais l’adapter deux fois de la même manière» C. Alexander Une base de savoir et de savoir-faire pour résoudre un problème récurrent dans un domaine permet d’identifier le problème à résoudre propose une solution consensuelle pour y répondre offre les moyens d’adapter cette solution

Nancy, décembre 2002 page 13 Type des connaissances Couverture Portée Nature de la solution Tech. de réutilisation Ouverture Granularité Patron de conception Produit Horizontale (générale) Conception Détaillée Conceptuelle Imitation puis Intégration Boîte blanche Faible : 2 à 4 classes Critères de caractérisation : application aux patrons [Gamma 95] E.Gamma Est = 20,4 Ouest = 30,6 Nord = 45,9 sujet observateurs Exemple : l’Observateur Intention : définir une ou plusieurs dépendances entre un sujet et ses observateurs de sorte que si le sujet change d'état, tous ses observateurs en soit informés et mis à jour. Motivation :

Nancy, décembre 2002 page 14 Type des connaissances Couverture Portée Nature de la solution Tech. de réutilisation Ouverture Granularité Patron de conception ProduitHorizontale (générale) Conception Détaillée ConceptuelleImitation puis Intégration Boîte blancheFaible : 2 à 4 classes Critères de caractérisation : application aux patrons [Gamma 95] Exemple : l’Observateur Solution: Sujet état_sujet lire_etat () modifier_etat () notifier () lier (Observeur) délier (Observeur) Observateur état-obs. mise_à_jour( ) 1..* observateurs pour tout o de observateurs o.mise_a_jour() return état-sujet

Nancy, décembre 2002 page 15 CoadGoF Systèmes de patrons SIGMA 2000 produit processus entreprise domaine générique analyse conception implantation SIP [Gzara 00] CoadGoF Ambler « Un langage de patrons est une collection structurée de patrons construits l’un sur l’autre pour transformer les besoins et les contraintes dans une architecture ». C. Alexander / J. Coplien Portée couverture Type de connaissance Un patron processus fournit une collection de techniques, d’actions et/ou de tâches à suivre pour le développement des logiciels. Ambler 98

Nancy, décembre 2002 page 16 Critères de caractérisation : application aux patrons architecturaux Type des connaissances Couverture Portée Nature de la solution Tech. de réutilisation Ouverture Granularité Patrons architecturaux ADL (Architecture Description languages) Architecture Composant- Architecture Système Composant- Système est-composant-de est-conforme-à Décomposition hiérarchique Conformité d’interface Intégrité de la communication Critères de conformité Conceptuelle Produit Horizontale Conception détaillée Imitation puis Intégration Boîte blancheFaible : 2 à 4 classes

Nancy, décembre 2002 page 17 Critères de caractérisation : application aux patrons architecturaux Point de vue architectural Niveau d’abstraction Domaine Implémentation Processus Flot de contrôle Flot de données Graphique Textuel Mon domaine Domaine connexe Tout Domaine.. Spécification architecture Haut-niveau Architecture détaillée Code source Type des connaissances Couverture Portée Nature de la solution Tech. de réutilisation Ouverture Granularité Patrons architecturaux Conceptuelle Produit/ Processus Horizontale Conception détaillée Imitation puis Intégration Boîte blancheFaible : 2 à 4 classes

Nancy, décembre 2002 page 18 Un patron constitue une base de savoir et de savoir-faire pour résoudre un problème récurrent dans un domaine Un système de patrons est une collection de patrons coordonnés intégrant une démarche de conception pour résoudre un problème complexe Patron & système de patrons Actuellement les systèmes de patrons sont des catalogues « papiers » - Peu organisés, formalisés, instrumentés De nombreux travaux : - Formalisation des solutions qu’est ce qu’une spécification générique ? Comment exprimer la variabilité ? - Expression des relations inter-patrons pour organiser les systèmes, exprimer les démarches,… - Mise en œuvre des patrons dans des ateliers de développement - Unification des formalismes existants….

Nancy, décembre 2002 page 19 Plan * Introduction sur la réutilisation * Cadre de référence pour la comparaison des composants * Les types de composants pour les SI ( métiers, architecturaux, patrons ) * Types de démarche : Pour et Par réutilisation * Synthèse sur les démarches les plus appliquées * Conclusion

Nancy, décembre 2002 page 20 Ingénieur d ’applications Ingénierie d ’applications Application Par réutilisation Pour la réutilisation Concepteur de composants Ingénierie de composants Bibliothèque de composants Développement Pour et Par Réutilisation

Nancy, décembre 2002 page 21 Plan * Introduction sur la réutilisation * Cadre de référence pour la comparaison des composants * Les types de composants pour les SI ( métiers, architecturaux, patrons ) * Types de démarche : Pour et Par réutilisation * Synthèse sur les démarches les plus appliquées * Conclusion

Nancy, décembre 2002 page 22 Démarches d’Ingénierie de systèmes à base de composants Trois méthodes sont sélectionnées – Catalysis [D ’Souza et al. 98] – Select perspective [Allen et al. 98] – Rational Unified Process (RUP)[Jacobson et al. 99]

Nancy, décembre 2002 page 23 Résumé des caractéristiques générales RUPSelectCatalysis Itératif et incrémental UML + extensions UML, E/R, CSC Catalyst Cool:Spex, Cool:Gen... Rational Rose, etc Select Component Factory Très complexe Moyennement complexe Processus de développement Notation Outils Case Complexité d’apprentissage

Nancy, décembre 2002 page 24 Étude détaillée de la prise en charge des composants (1/2) Logique, implémentation Pas de règles Pas d’indications Introduction des composants dans le cycle de développement Règles d’identifications des composants Niveau de décomposition Logique, implémentation CatalysisRUPSelect Pas de règles Pas d’indications

Nancy, décembre 2002 page 25 Oui avec OCL Framework avec des indications sur la manière pour les construire Rigueur dans la spécification des composants Réutilisation Non mentionné CatalysisRUPSelect Package de services sans précision sur l’approche à suivre pour les identifier et les construire Un processus supportant la gestion d’une librairie de composants réutilisables Logique : Type Implémentation: package, composant Représentation des composants Logique : sous système Implémentation: diagramme composants Logique : package de services Implémentation: diagramme composants

Nancy, décembre 2002 page 26 Faiblesses Introduction tardive des composants dans le cycle de développement (logique, implémentation) Manque de guidage du concepteur –Difficulté de passer des besoins aux composants –Pas de règles précises sur la granularité des composants (arrêt de la décomposition) Prise en charge partielle de la réutilisation

Nancy, décembre 2002 page 27 Plan * Introduction sur la réutilisation * Cadre de référence pour la comparaison des composants * Les types de composants pour les SI ( métiers, architecturaux, patrons ) * Types de démarche : Pour et Par réutilisation * Synthèse sur les démarches les plus appliquées * Conclusion

Nancy, décembre 2002 page 28 Conclusion Effervescence des travaux dans le domaine mais beaucoup de disparité. Diversité des composants : composants logiciels, métiers, architecturaux, patrons. Des solutions commencent à émerger mais : –Nécessité de standardiser la notion de « composant » –D’organiser les composants en fonction du problème (classification) –De définir des mécanismes d’intégration (assemblage, composition …) –De formaliser des démarches centrées réutilisation dès la phase d’analyse