Le développement par composants : principes de base ... › images › chouki_prez_univ_blida_tiber.pdf · 4/88. Développement par objets : avantages -suite-Les descripteurs des

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/

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é




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


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


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, ...


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


8/88


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


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


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 »


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-)


13/88

Développement par et pour la réutilisation


14/88

Exemple de description d'architecture à composants


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


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


17/88

Classifications des modèles à composants


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é




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, ...


22/88

Java EE et les applications N-Tiers


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


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


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, ...)


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)


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)


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


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)


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


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)


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


33/88

http://currencies.apps.grandtrunk.net/getlatest/USD/EUR

Frameworks pour le dév par composants

Spring pour le développement de composants modulaires fins


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


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


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 »


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>


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é


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


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, ...


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


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}


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)


45/88


OSGi pour le développement de composants modulaires de grande taille


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


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


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


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


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


52/88

Quelques implémentations connues de ce framework


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

http://www.osgi.org/Markets/

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


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


55/88


Systèmes de plugins pour le développement de composants d’extension


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++


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


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


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)


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">...


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);


63/88

Structure générale d’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


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)

...


67/88

Structure d’un plugin


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


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


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/


http://www.lirmm.fr/~tibermacin/ens/hmin304/

Plan de l’exposé





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


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


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


Documents

Le développement par composants : principes de base ... › images › chouki_prez_univ_blida_tiber.pdf · 4/88. Développement par objets : avantages -suite-Les descripteurs des