le développement par composants : principes de base ... › images ›...
TRANSCRIPT
Le développement par composants : principes de base, technologies courantes
et quelques projets de recherche
Chouki TIBERMACINEMél. : [email protected] : http://www.lirmm.fr/~tibermacin/
Plan de l’exposé
Les composants, une évolution des objets
Quelques frameworks de développement par composants
Travaux de recherche menés sur ce thème
C. TIBERMACINE 2/88
Plan de l’exposé
Les composants, une évolution des objets
Quelques frameworks de développement par composants
Travaux de recherche menés sur ce thème
C. TIBERMACINE 3/88
Développement par objets : avantages
Un objet : encapsulation de données + fonctions associées
Les données encapsulées peuvent être des référencesvers d'autres objets : notion de composition
Un objet peut être passé en argument : paramétrageplus riche (que le passage en argument de donnéesou de fonctions séparées) et connexions dynamiques
C. TIBERMACINELes composants = des objets++
4/88
Développement par objets : avantages -suite-
Les descripteurs des objets (classes) peuvent être réutilisés et spécialisés : notion d'héritage
L'héritage apporte un tas d'avantages :Réutilisation de codeConstruction de hiérarchies de conceptsSous-typage => polymorphisme
C. TIBERMACINELes composants = des objets++
5/88
Limites dans les pratiques actuelles dans le développement par objets
Problème de couplage fort
Entrelacement des aspects fonctionnels et non-fonctionnels
Entrelacement de la logique métier et l'architecture
C. TIBERMACINELes composants = des objets++
6/88
Couplage fort
Dans beaucoup d'applications à objets, à l'intérieur d'une classedonnée, on instancie un (ou plusieurs) objet(s) d'une autre (d'autres) classe(s)
class Editor {SpellChecker s = new SpellChecker();public edit(){ … s.check(...); }
}class SpellChecker {
public check(...){ ... }}
La classe Editor dépend alors fortement de la classe SpellChecker Si on décide d’utiliser l’instance d’une autre classe (FrSpellCheckerau lieu de SpellChecker, qui ne traite que l’anglais), il faut modifier le code de la première classe (Editor), recompiler, re-tester, ...
C. TIBERMACINELes composants = des objets++
7/88
Couplage fort – les solutions
1. Le patron de conception Factory :Une classe fabrique (usine) d'objetsUne classe avec des méthodes statiques qui ontpour seul rôle de créer et retourner des objets Les objets retournés peuvent avoir un type abstrait commun :type de retour de ces méthodesLes classes « clientes » dépendent : 1) de ces fabriqueset non des classes qu'elles instancient, et 2) des types abstraitscommuns aux objets « usinés » (et non des implémentations)
2. L'injection de dépendances :Constructeurs paramétrables (paramètres = objets cibles)Mutateurs (setters) dans les objets « dépendants »
Les frameworks Java EE et Spring fournissent des mécanismesd'injection automatique de dépendances
C. TIBERMACINELes composants = des objets++
8/88
C. TIBERMACINELes composants = des objets++
9/88
Dans le code des applications à objets classiques, on retrouveun mélange de code implémentant la logique métier et de codese chargeant des aspects non-fonctionnels : distribution,gestion des transactions, de la sécurité, ...
Les frameworks Java EE et Spring fournissent des mécanismespour séparer ces aspects
Ils proposent par ailleurs de gérer certains aspects non-fonctionnelsautomatiquement avec des comportements par défaut
Entrelacement des aspects fonctionnels et non-fonctionnels
C. TIBERMACINELes composants = des objets++
10/88
Dans le code des applications à objets, la description d'architecturen'est pas explicite
Elle est mélangée avec le code de la logique métier
Deux aspects de l'architecture sont noyés dans le code :L'expression du requis (fonctions requises des autres)La description des instanciations et des mises en placedes dépendances (les connexions)
Les frameworks Spring et OSGi permettent de séparer ces aspects
Entrelacement de la logique métier et l'architecture
C. TIBERMACINELes composants = des objets++
11/88
Le requis implicite :Dans une classe, on importe et utilise un type concretpour les attributs (~ ports requis) ou pour toute variable
Les instanciations statiques non-factorisées :Les fameux « new » (et/ou appels de constructeurs)répartis dans tout le code, alors qu'une partie peutêtre groupée : architecture statique
Les connexions codées en dur :Les affectations des attributs au milieu du code
Des solutions existent dans le monde objet, mais le développementpar composants se veut comme la solution unificatrice
Description d'architecture implicite
Définition du terme « composant »
Un composant : entité logicielle, prête à l’emploi, qui peutêtre paramétrée de diverses façons pour fonctionnerde façon spécifique dans différents contextesêtre assemblée de diverses manières avec d’autrescomposants compatibles
Définition la + citée (C. Szyperski. Component Software. Acm Press. 2002):« entité logicielle pré-fabriquée, définie par une ou plusieursinterfaces, qui peut être « composée » de diverses façonsavec d’autres, dans différents contextes, pour réaliserde nouveaux composites »
C. TIBERMACINELes composants = des objets++
12/88
Qu'est-ce qu’un composant concrètement ?
Un composant est une unité logicielle qui :décrit de façon explicite ses :
fonctionnalités fournies : signatures des opérations qu'il offre(interfaces fournies)fonctionnalités requises : signatures des opérations dont il
a besoin pour implémenter les fonctionnalités fournies[son architecture interne : liste des instances de ses
composants internes et leurs interconnexions]
est sujet à une instanciation et à une connexion avec d'autrescomposants (qui ont besoin de ses opérations / qui répondentà ses besoins -fournissent ses opérations requises-)
C. TIBERMACINELes composants = des objets++
13/88
Développement par et pour la réutilisation
C. TIBERMACINELes composants = des objets++
14/88
Exemple de description d'architecture à composants
C. TIBERMACINELes composants = des objets++
15/88
Un petit historique sur les composants
1960s Components would be a good idea ... Mass produced software components (M.D. McIlroy 1967) 1970s ... 1980s : Modules, Objects ... executable et pipe (unix) 1991 ...Composants distribués CORBA 1.1 1993 COM : Microsoft Component Object Model Empaquetage d’un programme dans un composant dotéd’interfaces. Précurseur de .NET 1997 JavaBeans et ActiveX :Construction de composés par assemblage de composants, schéma “MVC”, application à l’interfaçage 1997 ACME (Architecture Description Interchange Language), une tentative de langage minimal pour la définitionéchangeable de descriptions d’architectures
C. TIBERMACINELes composants = des objets++
16/88
Un petit historique sur les composants - suite
1998 SOFA (Software Applicances) : fournir une plate-forme pour le développement d’applications par “composition” d’un ensemble de composants.ADL : Langage de description d'arch. à base de composants
1999 Enterprise JavaBeans (EJB), composants distribués Java
2002 Fractal Component Model, Corba Comp. Model (CCM) 2002 ArchJava - Connect components - Pass Objects
2006 ... Langages de programmation et de modélisation par composants ... Evolution des langages à objets vers les composants ... Nombreuses visions et recherches
C. TIBERMACINELes composants = des objets++
17/88
Classifications des modèles à composants
C. TIBERMACINELes composants = des objets++
18/88
Il existe plusieurs classifications :Kung-Kiu Lau et Zheng Wang. Software Component Models. IEEE Transactions on Software Engineering,volume 33, num. 10, 2007I. Crnkovic, S. Sentilles, A. Vulgarakis et M.R.V. Chaudron.A Classification Framework for Software Component Models. IEEE Transactions on Software Engineering,volume 37, num. 5, 2010
Notre classification (thèse de P. Spacek) :Approches génératives : ADL → langages de prog. objet/autreApproches « Langages de programmation par composants »Approches Framework : sujet de la 2ème partie de l’exposé
Focus sur les frameworks Java
Plan de l’exposé
Les composants, une évolution des objets
Quelques frameworks de développement par composants
Travaux de recherche menés sur ce thème
C. TIBERMACINE 19/88
Frameworks de développement par composants
Java EE (Enterprise Edition) : composants distribués
Spring : Composants modulaires à granularité fine
OSGi : Composants modulaires à granularité grossière
Plugins : Composants d’extension
C. TIBERMACINEComposants Java EE
20/88
Java EE pour le développement de composants distribués
C. TIBERMACINEFrameworks pour le dév par composants
21/88
Framework Java EE
Anciennement J2EE devenu JEE (suite au passage de Java 2 à 5)
Une solution globale à base de composants pour les applications N-Tiers en Java
Spécification proposée par Oracle
Implémentations sous la forme de frameworks de développement et environnements de déploiement (serveurs d'applications)
Implémentations actuelles :Implémentation de référence : Glassfish d'OracleLibres : JBoss (WildFly) de Red Hat, JOnAS de OW2 (Bull), ...Propriétaires : WebSphere d'IBM, WebLogic d’Oracle, ...
C. TIBERMACINEComposants Java EE
22/88
Java EE et les applications N-Tiers
C. TIBERMACINEComposants Java EE
Application distribuée
Réseau physique
OS 2 OS 4
JVM /navigateur
Web
Objets de présentation
JSP - Servlets
Objets de persistanceEntity/DAO
OS 3
Serveurd'application
Glassfish/JBoss/...
BdD...
Objets de traitement métier
EJB
OS 1
Serveur Web/ d'application
Tomcat/...
SGBDMySQL/
ERP/...
OS 5
ClientJava/Web
Serveurd'applicationHibernate/
...
Services Web
23/88
Features de JEE
Supporte le développement de composants correspondantsà chaque niveau (Tier) de l'architecture N-Tier
Applications clientes : Java (POJO, Applets, JavaBeans, Java FX), ...Composants Web : HTML, CSS, JS, JSP, Servlets, XML, …Composants métier : Java, EJB, services Web, …
Fournit un mécanisme d'injection de dépendances, qui permetde satisfaire le requis des composants en termes de ressources(composants connus du serveur, des connexions aux BdD, …) :
Dans le passé (mais toujours possible) : configuration en XMLActuellement : simples annotations dans le code
Permet la séparation entre aspects fonctionnels et non-fonc. :développeurs se focalisent sur la logique métier→composants réutilisables
C. TIBERMACINEComposants Java EE
24/88
Composants Web JEE
Composant = archive constituée de programmes et de ressourcesWeb (transitant par le protocole HTTP) :
Des documents HTML, CSS et JavaScriptDes images, vidéos, …Des servlets et programmes JSPDes classes Java, JavaBeans, …
Servlets et programmes JSP : scripts côté serveur en JavaIls sont exécutés suite à la réception d'une requête HTTP(point d’entrée aux composants Web)Servlets : classes Java implémentant des méthodes doGet, doPost, ...Programmes JSP (équivalents aux scripts Php) : scripts Javatransformés en servlets lors du déploiement
Exécution gérée par un serveur Web, comme Tomcat
C. TIBERMACINEComposants Java EE
25/88
Composants EJB
Composants implémentant la logique métier de l'application
Composants écrits en Java avec le framework EnterpriseJavaBeans (EJB)
Quand utiliser des composants EJB ?Application doit passer à l'échelle (nombre grandissant d'utilisateurs)Intégrité des données avec les transactionsApplication peut avoir des utilisateurs divers (clients lourds,Web, d’autres composants, ...)
C. TIBERMACINEComposants Java EE
26/88
Enterprise JavaBeans
La spécification EJB a été développée par IBM en 1997puis adoptée par Sun Microsystems (racheté depuis par Oracle)en 1999
Version majeures :EJB 1.0 (1998), EJB 2.0 (2001), puis EJB 3.0 (2006)
La version mineure en vigueur est la 3.2 (mai 2013)
C. TIBERMACINEComposants Java EE
27/88
Sortes de composants EJB
Il existe deux sortes de composants EJBLes session beansLes message-driven beans (MDB)
A l'origine, il y avait une troisième sorte de composants : entity beans (devenus de simples classes pour POJO)
C. TIBERMACINEComposants Java EE
28/88
Session Beans
Un session bean encapsule une logique métier pouvant êtreinvoquée par un programme client (local ou distant)
Il existe trois sortes de session beans :Stateful : conserve un état conversationnel avec un client(dans les variables d'instances de la classe qui l'implémente)Stateless : ne conserve pas d'état
Solution efficace : le serveur gère un pool de beansBean implémente un service Web
Singleton : bean instancié une fois pour toute l'applicationGère un état partagé par plusieurs clientsS'occupe de l'initialisation ou du nettoyage de l'application
C. TIBERMACINEComposants Java EE
29/88
Message-Driven Beans (MDB)
Composants permettant aux applications JEE de s'exécuteren partie (en traitant des messages) de façon asynchrone
Ils sont utilisés lorsque l’on souhaite que le serveur effectuedes traitements qui ne sont pas bloquants pour le client
Ils agissent comme écouteurs de messages de type JMS(Java Messaging Service), le plus souvent
Ces messages peuvent être envoyées par n'importe quelautre composant JEE ou programme, en général
Les MDB ne maintiennent pas d'état conversationnel avec un client (ils sont gérés sous la forme de pool de beans)
C. TIBERMACINEComposants Java EE
30/88
Support des services Web
Java EE fournit les outils nécessaires pour développer et déployerdes services Web et leurs clients
Service Web : composant qui utilise des standards ouvertspour la description des interfaces, comme WSDL, et pourles protocoles de communication, comme SOAP, XML, REST, HTTP, Websockets, …
JEE masque les détails de ces technologies de bas niveau :favoriser l'interopérabilité (conversion en XML transparente, …)
2 possibilités : 1) invoquer les opérations de services Web (SW)depuis un bean et 2) publier un bean comme un SW
C. TIBERMACINEComposants Java EE
31/88
Produire des services Web
Un bean session sans état peut être publié comme service Web
Son interface sera considérée comme l'interfacedu service Web et sa classe, l'implémentation du SW
Il suffit de :Annoter la classe du bean avec @WebService (javax.jws)Annoter les méthodes publiées avec @WebMethod
Lors du déploiement, le serveur d'application génère le documentWSDL qui décrit le service Web (et fournit une interface Webde test des opérations du service)
C. TIBERMACINEComposants Java EE
32/88
Services Web REST
Il existe une autre forme de services Web plus légers : servicesWeb REST (REpresentational State Transfer)
Ce type de services s'appuient principalement sur HTTP(méthodes GET, POST, …) et rarement sur SOAP
Communication entre client et service Web plus légère(pour les messages, pas d'enveloppe SOAP dans les req/rep HTTP)
Invocation des opérations du service=accès à des ressources Web
Exemple :http://currencies.apps.grandtrunk.net/getlatest/USD/EUR
C. TIBERMACINEComposants Java EE
33/88
Frameworks pour le dév par composants
Spring pour le développement de composants modulaires fins
C. TIBERMACINE 34/88
Un peu d'histoire sur Spring
Décembre 1996 : JavaBeans - modèle de composants Javase limitant principalement aux interfaces graphiques
Mars 1998 : EJB - modèle de composants plus riche (transactions,persistance, ...)
répondant aux besoins réels des applications d'entreprise(mais rendant le code assez complexe et verbeux)
Juin 2003 : Spring - une simplification du développementdes applications d'entreprise (DI, AOP, ...)
développement de la logique métier des applications avec des POJOs (Plain-Old Java Objects)mise en place des autres aspects en utilisant un modèlede programmation déclarative
C. TIBERMACINEComposants Spring
35/88
Composants Spring
Un composant = une instance de classe Java standard(POJO)
Les classes d’une application Spring doivent être annotéesou une description d’architecture XML doit les accompagner
L’environnement d’exécution instancie automatiquementles classes (crée les composants) et les met en relation(crée les connecteurs) en utilisant l’injection de dépendances
C. TIBERMACINEComposants Spring
36/88
Injection de dépendances (DI)
Une entité externe à l'application (un objet de l’environnementd’exécution) :
crée les instances nécessaires qui composent une applicationles lie ensemble
De cette façon, les développeurs d'une application se focaliserontuniquement sur :1. la programmation de la logique métier de leur application2. la description de son architecture explicite, indépendammentde la logique métier
C. TIBERMACINEComposants Spring
37/88
Déclarer des composants (beans) dans Spring
Un bean = un objet d’une classe Java ordinaire implémentantune ou plusieurs interfaces (les interfaces fournies du composant)
Déclaration du bean dans la configuration XML :<bean id="emailer" class="fr.lirmm.marel.di.Emailer"/>
Le framework Spring est informé alors qu'il doit créer un objetde la classe ci-dessus et l'enregistrer avec l'id « emailer »
C. TIBERMACINEComposants Spring
38/88
Décrire des connecteurs entre composants
On demande une injection de dépendanceInjecter une référence en utilisant le constructeur :
<bean id="emailer" class="fr.lirmm.marel.di.Emailer"> <constructor-arg ref="editor" />
<constructor-arg ref="addressBook" /></bean>
<bean id="editor" class="fr.lirmm.marel.di.Editor">...
On peut injecter des valeurs (et non des références)<bean id="message" class="fr.lirmm.marel.di.Message"> <constructor-arg value="120" /></bean>
C. TIBERMACINEComposants Spring
39/88
Décrire des connecteurs entre composants -suite-
Propriété d'un bean ⟺ Propriété d'un JavaBean :Un attribut privé ayant un getter et un setter
Injecter une référence :<bean id="textEditor" class="fr.lirmm.marel.di.TextEditor"> <property name="spellChecker" ref="frSpellChecker"/></bean><bean id="frSpellChecker" class="fr.lirmm.marel.di.FrenchSC">
Il faut définir un constructeur sans paramètres, le cas échéantDans la DI, il est utilisé en premier, puis le setter est invoqué
C. TIBERMACINEComposants Spring
40/88
Reconfigurer l’architecture de l’application
Exemple de reconfiguration de notre application :...<bean id="textEditor" class="fr.lirmm.marel.di.TextEditor"> <property name="spellChecker" ref="enSpellChecker"/></bean><bean id="enSpellChecker" class="fr.lirmm.marel.di.EnglishSC">...
Aucune modification dans le code des classes des beans
Aucune re-compilation du code
Simple relancement de l'exécution de l'application
C. TIBERMACINEComposants Spring
41/88
Définir une architecture dynamique
Les connecteurs décrits précédemment sont déterminés de façonstatique (connecter un bean à un autre bean connu, ou injecterune valeur de type primitif)
Et si on voudrait définir des connecteurs qui sont résoluesdynamiquement ?
Nous pouvons utiliser SpEL : Spring Expression LanguageInvoquer des méthodes et accéder aux propriétés des beansUtiliser des opérations arithmétiques, logiques et de comparaisonTester des expressions régulièresManipuler des collections, ...
C. TIBERMACINEComposants Spring
42/88
Auto-connecter des composants
Objectif : éliminer du XML et laisser le framework Spring connecterautomatiquement les beans
Il existe quatre sortes d'auto-connexion :Par nom : demander au framework de trouver un bean ayant un id qui correspond au nom de la propriété du bean à auto-connecter
Par type : trouver un bean ayant un type affectable à une propriétédu bean à auto-connecter
Par constructeur : chercher des beans qui sont de types affectablesaux arguments du constructeur du bean à auto-connecter
Par auto-détection : par constructeur, puis par type
C. TIBERMACINEComposants Spring
43/88
Auto-connecter et auto-découvrir un composant
Appliquer l'annotation à une propriété directement :@Autowiredprivate Editor editor; Déclarer à Spring quels package il doit scanner automatiquement Pas besoin de déclarer les beans avec la balise <bean> Marquer une classe avec @Component :package fr.lirmm.marel.di;import org.springframework.stereotype.Component;@Componentpublic class Emailer …
Définir une classe décrivant l'architecture et l'annoter :@Configurationpublic class EmailerConfig {
// Mettre ici les méthodes de déclaration de beans}
C. TIBERMACINEComposants Spring
44/88
Avantages et limites de la DI dans Spring
Avantages de l'utilisation de ce type de frameworks :Un développeur n'a pas à définir un objet (Factory) qui retourneles instances créées et liées entre elles (tout est faitpar le framework)Plusieurs modes de DI auto. : par constructeur, par setter, ...Le framework s'occupe de l'injection virale des dépendances :les dépendances sont propagés à toutes les instances
Limites (pour la programmation par composants) :Aucune obligation à utiliser des interfaces requises et fourniesPas d'interface matching (sans sous-typage)
C. TIBERMACINEComposants Spring
45/88
Frameworks pour le dév par composants
OSGi pour le développement de composants modulaires de grande taille
C. TIBERMACINE 46/88
Composants « paquets » Java
Lorsqu’on développe des applications Java, l’unitéde déploiement (ou de distribution du code) est le JAR
Un JAR = une archive ZIP qui contient des classes et diversesressources + éventuellement un Manifest qui contientdes méta-données (indiquant si le JAR est exécutable, par ex)
Les applications Java de grande taille sont constituéesde plusieurs centaines de JAR
Est-ce que ces archives de code offrent suffisammentde modularité ? (= composants, avec requis explicites … ?)
C. TIBERMACINEComposants OSGi
47/88
Archives Java en pratique
Un JAR n'est qu'un regroupement de classes, interfaces et autresressources au sein d'une même structure réutilisable
Une fois placé dans le classpath, le contenu d'un JARse dissout dans l'espace de classes, avec les contenusde tous les autres JARs
Par conséquent, chaque classe publique dans ce JAR estaccessible par n'importe quelle autre classe (dans les autres JARs)
Les frontières du JAR disparaissent donc complètementà l'exécution
C. TIBERMACINEComposants OSGi
48/88
Archives Java en pratique -suite-
Les archives Java n'offrent aucun moyen de gérer les versions
Dans de grosses applications où on utilise beaucoup de librairies(sous la forme de JARs) :
Si deux composants différents de l'application utilisentla même librairie mais en deux versions différentes :
l'une des librairies écrasera l'autre
C. TIBERMACINEComposants OSGi
49/88
C'est quoi OSGi ?
Un framework Java pour :La programmation modulaire en JAVA : implémentationd'architectures à base de composants dans une machinevirtuelle Java (JVM)
La gestion automatique des dépendances entre composants
L'implémentation d'architectures orientées services dansune même JVM
C. TIBERMACINEComposants OSGi
50/88
C'est quoi un composant (= bundle) OSGi ?
Un composant JAVA ayant des dépendances expliciteset encapsulant son implémentation
Concrètement, il s'agit d'un JAR ayant :un Manifest (META-INF/MANIFEST.MF) avec des méta-données spécifiques (permettant entre autres plus de modularité) :
Nom du composantSa versionSes dépendances (interfaces requises), mais aussi sesinterfaces fourniesSes paramètres de déploiement...
une éventuelle classe « Activator » gérant son cycle de vie
C. TIBERMACINEComposants OSGi
51/88
Historique du framework OSGi
OSGi Alliance :Un consortium à but non lucratif, regroupant entre autresIBM, Oracle, SAP, Motorola, Samsung, Nokia, ...Créé en mars 1999Fournit des spécifications pour proposer des solutions JAVAplus robustes, modulaires, dynamiques, …
Distributions du framework :Spec OSGi Release 1 : 2000Spec OSGi Release 2, 3, 4 et 5 : 2001, 2003, 2005 et 2012Spec OSGi Release 6 : 2014
C. TIBERMACINEComposants OSGi
52/88
Quelques implémentations connues de ce framework
C. TIBERMACINEComposants OSGi
Une multitude d'implémentations : open source, commerciales, pour environnements mobiles, domotiques, ... Les plus connues (open source) :
Eclipse Equinox : l'implémentation de référenceDéveloppée par IBM et fournie sous la licence EPL (EclipsePublic License)Eclipse est construit au dessus d'EquinoxUn plugin Eclipse = un bundle++
Apache Felix (anciennement, Oscar d'ObjectWeb) :Développée par Apache et fournie sous
la licence Apache License 2
Liste complète (impl. certifiées) : http://www.osgi.org/Markets/
53/88
Comment OSGi apporte la modularité à Java ?
Encapsulation :Chaque composant OSGi est chargé à l'exécution dans sonpropre espace de classes (indépendant des autres)Tout le contenu d'un composant (ses classes) est donc privé,sauf certaines parties qui sont explicitement exportéesdans le manifest (ses interfaces fournies et requises)Chaque implémentation interne d'un composant peut évoluerindépendamment des autres composants
Service Registry : Implémentation du patron « Service Locator »Un composant peut publier ses services dans un annuaireUn composant peut dépendre des services publiés par d'autrescomposantsLes services sont connus par leurs interfaces publiés (et nonleur implémentation) : couplage faible
C. TIBERMACINEComposants OSGi
54/88
Comment OSGi apporte la modularité à Java ?
Versions parallèles d'un composant :Chaque composant est publié dans un espace de classes proprePlusieurs versions d'un même composant peuvent co-existerdans une même application
Reconfiguration dynamique :Il est possible de charger dynamiquement des modules (pendantl'exécution de l'application)Un composant peut être remplacé dynamiquement parune nouvelle version de celui-ci
Nommage fort :A la différence des JARs traditionnels, les composants OSGi ontun nom et un numéro de version : identification uniqueBundle Symbolic Name
C. TIBERMACINEComposants OSGi
55/88
Frameworks pour le dév par composants
Systèmes de plugins pour le développement de composants d’extension
C. TIBERMACINE 56/88
Principe général des systèmes de plugins
Une grande application qui possède beaucoup d’utilisateur :Fournit le moyen aux développeurs d’écrire des composantsqui étendent ses fonctionnalités
Ce système de plugins fourni par cette application est basée sur :des contrats déclarant des types précis à implémenter par les pluginsun mécanisme d’inversion de contrôle : des callbacksimplémentés par les plugins sont appelés automatiquement
Exemples d’applications fournissant un système de plugins :IDE : Eclipse et NetbeansNavigateurs Web : Chrome, Firefox, Edge, ...
C. TIBERMACINEComposants Eclipse
57/88
Principe général du système de plugins d’Eclipse
Eclipse est une application constituée de +ieurs centainesde bundles OSGi (978 bundles dans Eclipse Neon JEE)
Les bundles OSGi d’Eclipse peuvent être étendus ou configurés :ils déclarant des points d'extensionils définissant un contrat avec leurs extensions
D'autres bundles apportent des contributions sous la formed'extensions :
en fournissant des données ou en indiquant des classesà exécuter par Eclipse (à instancier, puis invoquerleurs méthodes) qui respectent le contrat
Ces bundles s'enregistrent auprès d'un « Extension Registry » Plugin = Bundle++
C. TIBERMACINEComposants Eclipse
58/88
Relation Extension-Point d'extension
Dans chaque plugin Eclipse, nous disposons d'un fichierde configuration : plugin.xml Celui-ci comporte les déclarations des points d'extensionet des extensions du plugin Exemple de point d'extension :<extension-point id="monPlugin.messages"
name="monPlugin.messages"/> Exemple d'extension :<extension point="monPlugin.messages" id="plug.msgs">
<message value="Bonjour à tous"></message></extension>Notez que dans Eclipse, il y a un environnement de développementde plugins (PDE) qui facilite l'édition de ces éléments
C. TIBERMACINEComposants Eclipse
59/88
Contrat entre extensions et points d'extension
Le contrat entre une extension et un point d'extension peut êtredécrit par un schéma XML défini dans le point d'extension :<extension-point id="..." name="..."
schema="schema/....exsd" />
Ce schéma XML décrit la structure que doivent respecterles fichiers XML définis par les extensions (exemple précédent)
Ce fichier XML comporte soit :une configuration : des données fournies au plugindéclarant le point d'extension (ex. précédent : messagesHello World -> éléments de configuration)une extension proprement dite : un élément de config. XMLdéfinissant un attribut ayant comme valeur le nom d'une classe
C. TIBERMACINEComposants Eclipse
60/88
Extensions apportant des programmes (classes)
Exemple : plugin affichant des messages de façon graphique(un autre plugin peut afficher les messages sur la sortie standard)
L'extension dans plugin.xml :<extension point="plugin1.viewers" id="plugin2.msgs">
<afficheur class="myPlug.GUI_MessageViewer"></afficheur>
</extension>
Le schéma XML représentant le contrat indique qu'il doit y avoirun élément nommé « afficheur » ayant un attribut nommé « class »de type Java (les noms de l'élément et de son attribut sont libres)
C. TIBERMACINEComposants Eclipse
61/88
Extensions apportant des programmes (classes) -suite-
Il est possible d'indiquer une interface ou une classepour lesquels les extensions doivent fournir une implémentationou une spécialisation, respectivement
Exemple : indiquer le nom d'une interface IViewer (interfacerequise du composant)
public interface IViewer {public void view(String msg);
}
La classe indiquée dans l'extension implémente cette interface :<extension ...>
<afficheur class="myPlug.GUI_MessageViewer">...
C. TIBERMACINEComposants Eclipse
62/88
Lancer l'exécution des extensions
Ce que fait Eclipse :A partir du code qui s'exécute dans le plugin qui déclarele point d'extension (par exemple, dans sa classe Activator, ou en réponse à une action effectuée sur une extension graphiquefournie par ce plugin (voir plus loin)), rechercher dans le registryles extensions qui contribuent au point d'extension et les lancer :IConfigurationElement[] elements = registry.getConfigurationElementsFor("...");...Object o = e.createExecutableExtension("class");if (o instanceof IViewer)
((IViewer)o).view(msg);
C. TIBERMACINEComposants Eclipse
63/88
Structure générale d’Eclipse
C. TIBERMACINEComposants Eclipse
Eclipse n'est pas un programme monolithique
Il est constitué d'un noyau comportant un chargeur de pluginset un nombre important de plugins (des centaines)Pour savoir combien de plugins comporte votre installationd’Eclipse : lancer Eclipse sur l’invité de commandes avec l’argument -console
Le noyau est une implémentation d'OSGi (Equinox)
64/88
Catégories de plugins trouvés dans Eclipse
C. TIBERMACINEComposants Eclipse
Core : des plugins de bas niveau fournissant les servicesde base de traitement des extensions, ... SWT (Standard Widget Toolkit) : librairie générale de widgetspour construire des interfaces graphiques JFace : une librairie graphique construite sur SWT (comportedes widgets plus riches) Workbench Core et Workbench UI : plugins utilisés par Eclipsefournissant la gestion des projets, des éditeurs, des vues, ... JDT (Java Development Tooling) : plugins utilisés par Eclipsepour la programmation en Java PDE (Plugin Development Environment)
65/88
Principe général du système de plugins des navigateurs
Le mécanisme des extensions Web (WebExtensions) est un système multi-navigateurs pour développer des pluginsqui viennent enrichir les fonctionnalités des navigateurs
Théoriquement, un même plugin (composant) devrait fonctionnersur Firefox, Chrome et Opera, et sur Microsoft Edge (moyennantquelques petits changements)
Ces plugins sont écrits avec les standards du Web : HTML, CSSet JavaScript (avant, c’étaient des langages dédiés)
C. TIBERMACINEComposants d’extension Web
66/88
Plugins possibles
Changer l’apparence de certains sites Web (les adapter auxutilisateurs ayant un handicap – l’accessibilité, par exemple)
Changer le contenu de certains sites Web (supprimer les messages publicitaires, par exemple, comme Adblock)
Archiver toutes les navigations effectuées par l’utilisateuret les ré-exécuter automatiquement à sa demande
Télécharger les médias (vidéos, par exemple) qui sont visionnéssur le navigateur (comme Download Helper)
...
C. TIBERMACINEComposants d’extension Web
67/88
Structure d’un plugin
C. TIBERMACINEComposants d’extension Web
Implémentent la logique métier du plugin
Scriptent le comportement et l’apparencedes pages Web visitées
Ajoutent des boutons à la barre d’outilsdu navigateur (actions permanentes)
Ajoutent des boutons à la barre d’adressesdu navigateur (actions propres à une page)
Ajoutent une page pour permettreaux utilisateurs de paramétrer le plugin
Groupent les ressources (images, par ex)utilisées par le plugin
68/88
Événements « interceptables » par un plugin
C. TIBERMACINEComposants d’extension Web
Requête
Réponse
onErrorOccured est un événement qui peut être propagé à n’importe quel instant(coupure réseau, par exemple)
Les entêtes pas encore prêts(annuler ou rediriger la requête)Les entêtes prêts
(les modifier)
Les entêtes de la réponsereçus (les modifier)
Le serveur initie une redirection Le serveur demande
une authentification
69/88
Exemple d’interception de requêtes HTTP
C. TIBERMACINEComposants d’extension Web
Exemple : journaliser les requêtes HTTP// manifest.json{ "description": "Demonstrating webRequests", "manifest_version": 2, "name": "webRequest-demo", "version": "1.0", "permissions": ["webRequest","<all_urls>"], "background": {"scripts": ["background.js"]} }// background.jsfunction logURL(requestDetails) { console.log("Loading: " + requestDetails.url);}chrome.webRequest.onBeforeRequest.addListener( logURL, {urls: ["<all_urls>"] });
70/88
Pour plus de détails ...
Cette partie de l’exposé est une synthèse des cours magistrauxdonnés dans un module du master 2 génie logiciel à l’universitéde Montpellier
Les dispos et les sujets de TP sont disponibles ici :http://www.lirmm.fr/~tibermacin/ens/hmin304/
C. TIBERMACINE 71/88
Plan de l’exposé
Les composants, une évolution des objets
Quelques frameworks de développement par composants
Travaux de recherche menés sur ce thème
C. TIBERMACINE 72/88
Modèles, langages et méthodes pour promouvoirle développement par et pour la réutilisation
C. TIBERMACINETravaux de recherche sur les composants
73/88
Description d’architecture dans les modèles et programmesréutilisables :
Modèle de composants pour la spécification de contraintesd’architectureMéthode de génération de composants et de services à partirde spécifications brutes de contraintes d’architectureLangage de programmation par composants
Ré-ingénierie et évolution des applications pour une meilleure réutilisation
Migration de logiciels vers les composants et les services WebÉvolution des applications à services par intégration de patrons
Classification des composants et des services Web pour assisterle développement par réutilisation
C. TIBERMACINETravaux de recherche sur les composants
74/88
Modèle de composants pour la spécification de contraintes d’architecture
Contrainte d'architecture
Une contrainte est une règle que doit respecter une descriptiond'architecture pour satisfaire un besoin non-fonctionnel (de qualité)
Elle restreint :le nombre d'éléments dans une architecture (composants, ports,connecteurs, ...)la configuration de ces éléments (quel composant est connectéà quel autre composant, ...)...
Nous nous limitons ici aux contraintes qui portent sur la structure(certaines descriptions d'architecture incluent une spécificationcomportementale : machines d'état, par exemple. Nous neles traitons pas ici)
Chouki TIBERMACINE
75/88
Exemple : style d'architecture en couches
Chouki TIBERMACINE
Contraintes textuelles :Chaque couche doit être connectée
Chaque couche doit être connectée à au plus deux autrescouches
Le nombre de couches qui sont connectées à une seule autrecouche est égal à 2 (les couches top et bottom)
76/88
Exemple : style d'architecture en couches -suite-
Chouki TIBERMACINE
Contraintes OCL :-- Chaque couche doit être connectéeself.internalArchitecture.instance->forAll(c: ComponentInstance | c.port.inConnector->union(c.port.outConnector)->notEmpty()) and-- Chaque couche doit être connectée à au plus deux autres-- couchesself.internalArchitecture.instance->forAll(c: ComponentInstance | c.port.inConnector.toPort.instance->union(c.port.outConnector .fromPort.instance)->asSet()->size() <= 2) and-- Le nombre de couches qui sont connectées à une seule autre-- couche est égal à 2 (les couches supérieure et inférieure)...
77/88
Constats et problématique
Chouki TIBERMACINE
Les contraintes architecturales sont souvent réutilisées
Quand elles sont réutilisées, elles sont sujettesà une personnalisation avant leur association à une descriptiond'architecture
Les contraintes architecturales sont sujettes à une composition(concevoir des contraintes architecturales complexes à partirde contraintes plus simples)
78/88
Objectifs de ce travail
Chouki TIBERMACINE
79/88
Idée générale : composants-contraintes
Chouki TIBERMACINE
Construire les contraintes d'architecture sous la formede composants, dits « composants-contraintes »
Ces composants exportent des ports (Input) décrits pardes interfaces contenant des opérations pour vérifierdes contraintes (contraintes que ces composants savent vérifier)
Ces composants peuvent définir des ports (Output) décritspar des interfaces contenant des opérations requises(contraintes dont ces composants ont besoin et qui sont vérifiéespar d'autres composants)
Ces composants peuvent être assemblés avec des connecteurs
80/88
Implémentation des composants-contraintes
Chouki TIBERMACINE
Implémentations du méta-modèle des composants-contraintes :Nouveau méta-modèle EMF/GEF sous Eclipse1
Profil UML 2.4 sous RSA (Rational Software Architect)2
Langage de programmation Compo3
Les contraintes sont évaluées sur la base du plugin OCL d'Eclipse
Évaluation statique, à la conception, des contraintes architecturales1C. Tibermacine et al. Component-based Specification of Software Architecture Constraints.Dans les actes du 14th International ACM SIGSOFT Symposium on Component-Based Software Engineering (CBSE'11), Boulder, Colorado, USA, Juin 2011. ACM Press.2C. Tibermacine et al. Software Architecture Constraint Reuse-by-Composition.Dans la revue Future Generation Computer Systems, vol. 61, août 2016, 37-53. Elsevier.3P. Spacek et al. A Component-based meta-level architecture and prototypical implementation of a reflective Component-oriented Programming and Modeling language. Dans les actes du 17th International ACM SIGSOFT Symposium on Component-BasedSoftware Engineering (CBSE'14), Lille, France, Juin 2014. ACM Press.
81/88
C. TIBERMACINETravaux de recherche sur les composants
82/88
Méthode de génération de composants et de services à partir de spécifications brutes
de contraintes d’architecture
Problématique
Chouki TIBERMACINE
Des catalogues de contraintes se sont formés
Les contraintes sont écrites sous la forme de spécificationsbrutes non-structurées
Elles n’offrent pas suffisamment de réutilisation et de paramétrage
Elles sont composées de parties indépendantes ayant leurssémantiques propres, et qui peuvent être réutilisées
Le modèle de composants présenté avant répond à ce besoin
Il n’y a aucun moyen de traduire automatiquementces contraintes en composants
83/88
Objectif du travail
Chouki TIBERMACINE
Objectif général : Rendre les spécifications des contraintesexistantes des entités réutilisables, personnalisableset composables en les transformant automatiquementen composants Dans ce travail :
Nous avons spécifié, implémenté et expérimenté un processusde traduction automatiqueCe processus prend en entrée des contraintes d’arch. OCLIl génère des composants-contraintes CLACSIl génère ensuite des composants-contraintes et des services-contraintes OSGi qui, pour vérifier les contraintes :
utilisent Java Reflect pour l’introspection et interrogent l’annuaire de services pour analyserles fournisseurs et les consommateurs de services
84/88
Processus de traduction
Chouki TIBERMACINE
Processus à trois étapes :1. Refactoring de contraintes OCL pour :
Extraire les déclarations et en faire des composants-requêtesDécouper le reste en « morceaux » réutilisablesLes rendre paramétrablesLes re-contextualiser vers les méta-classes appropriées
Résultat : Un ensemble de définitions OCL ayant comme contextela méta-classe ComponentUn ensemble de définitions OCL associées à différentes méta-classes, utilisables pour définir des invariants
85/88
Processus de traduction1 -suite-
Chouki TIBERMACINE
2. Construction de composants-contraintesGrouper les définitions dans les composants (mesure de similarité entre contraintes OCL)Migration du méta-modèle UML vers le méta-modèle CLACSGénérer les composants-contraintes et les composants-requêtes
Résultat : Composants vérifiables de façon statique sur des descriptions d’architecture (phase de conception)
86/88
1S. Kallel et al. Automatic Translation of Architecture Constraint Specifications into Components. Dans les actes du 9th European Conference on Software Architecture (ECSA'15), Dubrovnik/Cavtat, Croatia, September 2015. Springer.
Processus de traduction1 -suite-
Chouki TIBERMACINE
3. Production de composants-contraintes et services-contraintesOSGi
Construction de la structure des composants OSGiGénération de code de vérification en utilisant String TemplatesPublication des opérations comme services dans l’annuaire
Résultat : Composants et services vérifiables :sur des programmes à composants ou à services (phase d’implémentation)À l’exécution de ces programmes
Expérimentations faites sur un catalogue d’une quinzainede contraintes
87/88
1S. Kallel et al. Generating Reusable, Searchable and Executable "ArchitectureConstraints as Services". A paraître dans la revue JSS en 2017
Merci de votre attention
C. TIBERMACINE 88/88