Architecture

L’atelier a été développé sur le principe d’architecture à base de plugins d’Eclipse. Les plugins officiels EMF, UML et OCL sont utilisés et de nouveaux plugins ont été implémentés. Chacun d’eux contribuent à Eclipse, en utilisant les points d’extensions de cette plateforme. Ces plugins et leurs relations de dépendances sont montrés en figure4.19. Il s’agit de :

Plugins spécifiques à l'atelier

Adaptateur de modèles

(UML vers formel, formel vers UML) _{Profile UML}

(M) Moteur de sous-modèles (AT) Moteur d'aspectual templates Editeur d'aspectual templates Visualisation de relations de sous-modèles Visualisation d'aspectual templates Plugins spécifiques à Eclipse EMF UML OCL uses

Figure 4.19 – Architecture de l’atelier de modélisation

- Un adaptateur de modèles : permettant l’échange de modèles entre les deux moteurs cités plus haut, celui-ci est présenté en sous-section 4.2.3.1.

- Le profil UML : il étend le plugin UML d’Eclipse avec les contraintes OCL et les stéréotypes présentés plus haut,

- Le moteur de sous-modèles : utilisé par le moteur d’aspectual templates, il permet de déterminer les relations d’inclusions entre des modèles et d’effectuer des opérations sur ceux-ci (extraction, fermeture d’un ensemble d’éléments de modèles),

- L’outil de visualisation d’aspectual templates : il étend Eclipse avec une nouvelle vue permettant d’avoir une représentation graphique d’un modèle UML ou d’un modèle UML étendu avec le profil,

- L’outil de visualisation des relations d’inclusion entre modèles : Eclipse est étendu avec cette nouvelle vue qui permet d’avoir une représentation graphique des relations de sous-

modèles. Cet outil est utilisé dans le cadre de la recherche de modèles, notamment avec la fonctionnalité de recherche de modèles sur lesquels un template est applicable (cf. figure

4.16),

- Le moteur d’aspectual templates : implémente les fonctionnalités liées aux templates, i.e. application des stéréotypes, paramétrisation, inférence et complétion de bindings et ex- traction des constituants d’un template,

- L’éditeur d’aspectual templates : l’éditeur du plugin UML est étendu pour cela, ajoutant des fonctionnalités qui permettent :

. d’importer ou de spécifier de nouveaux aspectual templates et leurs applications, en accédant aux fonctionnalités implémentées dans le moteur de templates,

. de vérifier les contraintes portant sur le modèle paramètre des aspectual templates et leurs applications. Pour cela, l’éditeur accède au profil UML.

Le bénéfice d’une telle architecture est la modularité. En effet, certains plugins sont utilisables indépendamment les uns des autres. Cela permet de les intégrer à d’autres outils compatibles avec EMF et UML, tels des moteurs de construction et de transformation de modèles, des vérificateurs de modèles UML ou encore des éditeurs de modèles. Les plugins pouvant être utilisés indépendamment des autres sont :

- le moteur de sous-modèles et l’adaptateur de modèles,

- l’outil de visualisation des relations d’inclusion entre modèles, avec le moteur de sous- modèles et l’adaptateur de modèles,

- l’outil de visualisation d’aspectual templates et le profile UML.

4.2.3.1 Moteur d’aspectual templates

Le moteur d’aspectual templates est constitué de quatre classes de helpers, présentées en figure

4.20. Ces classes permettent de séparer les opérations sur la structure même du template (As- pectualTemplateHelper ) de celles sur la signature de celui-ci (AspectualTemplateSignatureHelper )

AspectualTemplateProfileHelper getProfile() : Profile[0..1]

isAspectual(pkg : Package) : boolean[0..1]

isAspectual(signature : TemplateSignature) : boolean[0..1] isAspectual(binding : TemplateBinding) : boolean[0..1] makeAspectual(pkg : Package) : boolean[0..1]

makeAspectual(signature : TemplateSignature) : boolean[0..1] makeAspectual(binding : TemplateBinding) : boolean[0..1] isGenerative(binding : TemplateBinding) : boolean[0..1] makeGenerative(binding : TemplateBinding) : boolean[0..1]

AspectualTemplateSignatureHelper signature : TemplateSignature [0..1] complete() : void[0..1] AspectualTemplateBindingHelper bindings : TemplateBinding [*] getFormalElements() : TemplateParameter[*] getActualElements() : Element[*] completeFormalParametersTotally() : void[0..1] completeFormalParametersPartially() : void[0..1] getInferedTemplateBindings() : TemplateBinding[*] findCompatibleHierarchy(boundModel : Package, modelsInSpace : Package) : Package[*]

unbind(template : Package, boundPackage : Package) : Package[0..1]

AspectualTemplateHelper template : Package [0..1]

getSpecificPackage() : Package[0..1]

getSignatureElements() : ParameterableElement[*] extractModel(modelConstituents : Element) : Package[0..1] apply(tb : TemplateBinding) : void[0..1]

instantiate(tb : TemplateBinding) : Package[0..1] promote(pes : ParameterableElement[*]) : void[0..1] restrict(tps : TemplateParameter[*]) : void[0..1]

getBoundSubstitutions(model : Package) : TemplateBinding[*]

Figure 4.20 – Architecture du moteur d’aspectual templates

et sur les bindings (AspectualTemplateBindingHelper ). Par exemple, l’opération “promote” (cf. section 4.1.3.3), définie dans AspectualTemplateHelper, utilise “dependents” (cf. section 4.1.2.2) de AspectualTemplateSignatureHelper. Ces classes sont détaillées ci-après :

- AspectualTemplateProfileHelper : Offre des opérations pour la définition du profil4. . Application des stéréotypes : L’application des stéréotypes est effectuée sur les éléments

cités précédemment via les opérations “makeAspectual” et “makeGenerative”.

. Test de présence des stéréotypes : Cette opération teste si les stéréotypes associés au package et à la signature sont cohérents par rapport au binding sélectionné (Aspec- tualTemplateBinding ou InstantiateTemplateBinding).

Cette opération est notamment utilisée par certaines des fonctionnalités implémentées dans la classe AspectualTemplateHelper, présentée ci-après.

- AspectualTemplateHelper :

. Accès aux constituants d’un aspectual template : La classe permet d’obtenir les consti- tuants d’un aspectual template, à savoir le modèle paramètre et le modèle spécifique ainsi que les éléments de ces derniers (“getSpecificTemplateElements”, ...). Ces consti- tuants sont utilisés par les fonctionnalités suivantes.

. Opérations sur les aspectual templates : L’éditeur accède à celles-ci, e.g. pour appliquer un aspectual template (“apply(binding : TemplateBinding)”).

- AspectualTemplateSignatureHelper : Offre des opérations pour la définition de la signature d’un template (i.e. le modèle paramètre). Un exemple d’opération est la complétion de la signature avec “closure” (cf. section 4.1.2.2), afin d’obtenir un modèle paramètre bien formé.

Cette complétion s’effectuant avec des éléments du modèle spécifique, la classe Aspectual- TemplateHelper est utilisée (opération “getSpecificPackage”).

- AspectualTemplateBindingHelper :

. Complétion (partielle et totale) d’un binding : Les opérations permettant cette com- plétion (“completeFormalParametersTotally” et “completeFormalParametersPartially”) font appel à l’opération “getSignatureParameterables” de la classe AspectualTemplate- HelperUtil, puisque le binding est complété avec des éléments du modèle paramètre. . Inférence de bindings : L’opération “getInferredTemplateBindings” retourne les

bindings permettant d’appliquer un aspectual template sur un contexte (mise en œuvre de l’opérateur “subsInference”, cf. section4.1.3.6).

Connexion et échange de modèles avec le moteur de sous-modèles Le moteur de templates fait appel aux fonctionnalités du moteur de sous-modèles. Celui-ci a été implémenté par l’équipe et intégré à Eclipse et son framework de modélisation (EMF ). Ce moteur fournit un ensemble de fonctionnalités permettant :

- de déterminer comment les modèles sont reliés entre eux par des relations d’inclusion, - de hiérarchiser les modèles selon ces relations,

- de calculer la fermeture (closure) d’un ensemble d’éléments de modèle dans un modèle, - de compléter un ensemble d’éléments de modèle avec ceux qui en dépendent (dependents)

dans un modèle,

- d’extraire un sous-modèle à partir d’un modèle, via l’opérateur extract présenté dans la section précédente.

Ces fonctionnalités sont offertes par le moteur aux autres outils inclus dans l’environnement Eclipse, tel le moteur de templates. Elles sont valables pour n’importe quel modèle, moyennant l’implémentation d’un adaptateur afin de convertir le modèle au format utilisé par le moteur de sous-modèle.

Afin que le moteur d’aspectual templates puisse échanger des modèles avec le moteur de sous- modèles, deux conversions sont effectuées par un adaptateur de modèles (cf. figure 4.21) :

- UML vers le format de représentation de modèles considéré (a) : Lorsque le moteur d’aspectual templates utilise des opérations définies dans le moteur de sous-modèles (e.g. closure), il utilise l’adaptateur. Celui-ci prend en entrée un package UML et le converti au format requis par le moteur de sous-modèles.

- Format de représentation de modèles vers UML (b) : Lorsque le moteur de sous-modèles a effectué toutes les opérations sur le modèle concerné, il le retourne au moteur d’aspectual templates via l’adaptateur. Ce dernier transforme alors le modèle en package UML.

(AT) Moteur d'aspectual templates Moteur de sous -modèles Adaptateur de modèles (a) (b)

Chapitre 5

Application : Modélisation d’un serveur

REST d’agrégation d’informations

5.1

Objectif

Le but de cette application est de valider l’approche IDM basée sur les templates (cf. chapitre

3.2) au travers d’un scénario de modélisation incrémentale d’un serveur REST d’agrégation d’in- formations.

Différents opérateurs de construction (merge, apply, instantiate), de décomposition (extract, un- bind ), de paramétrisation (promote, restrict ) ainsi que de recherche de modèles et d’inférence de substitutions (findCompatibleHierarchy, getBoundSubstitutions), détaillés en section4.1, sont utilisés afin de répondre aux spécifications décrites en sous-section 5.2.1.