2019 ACM/IEEE 22e conférence internationale sur les langages et systèmes d'ingénierie pilotés par les modèles Companion
(MODÈLES-C)
Vers une ingénierie de modèle basée sur la recherche évolutive
avec l'échelle MDEOptimiser
Alexandru Burdusel
Département d'informatique
King's College de Londres
30 Aldwych, Londres, WC2B 4BG
alexandru.burdusel@kcl.ac.uk
Abstrait—Exécuter des expériences scientifiques à l'aide de la recherche
Les outils d'ingénierie des modèles (SBME) sont une tâche complexe, qui pose
un certain nombre de défis, allant de la définition d'un flux de travail
d'expérience au réglage des paramètres, en passant par la recherche des
ressources de calcul optimales, la collecte et l'interprétation des métriques et
la reproductibilité de l'ensemble du processus.
Malgré la prolifération de matériel facilement accessible, en raison de la
disponibilité accrue des fournisseurs d'infrastructure en tant que service, de
nombreux outils SBME utilisent rarement cette technologie pour accélérer
l'expérimentation. L'exécution de nombreuses expériences sur une seule
machine implique des temps d'attente beaucoup plus longs et réduit la
capacité d'augmenter la vitesse des itérations lors de la recherche SBME,
ralentissant ainsi l'ensemble du processus.
Dans cet article, nous introduisons un langage spécifique au domaine
(DSL) et un cadre qui peuvent être utilisés pour configurer et exécuter des
expériences à grande échelle, sur une infrastructure cloud, de manière
reproductible. Nous décrirons notre architecture DSL et framework ainsi
qu'un exemple pour montrer comment une étude de cas peut être évaluée à
l'aide de deux outils d'optimisation de modèle différents.
Index des termes—ingénierie pilotée par modèle, reproductible
recherche, recherche évolutive, ingénierie de modèle basée sur la recherche,
workflow, cloud, middleware
je. jeNTRODUCTION
L'ingénierie des modèles basés sur la recherche (SBME) est une méthodologie
qui combine des techniques de recherche avec l'ingénierie dirigée par les modèles,
pour aider les experts du domaine à trouver des modèles optimaux qui satisfont aux
contraintes du métamodèle [1]–[5]. L'un des problèmes rencontrés par les
chercheurs SBME est le temps d'exécution long et les ressources de calcul
considérables requises par les outils SBME pour trouver de bons résultats.
Des expériences de recherche typiques visent à évaluer plusieurs
configurations, pour au moins un outil SBME. Chaque configuration se
compose d'un ensemble de paramètres, d'études de cas et de modèles
d'entrée. De telles approches systématiques génèrent un grand nombre
de permutations d'expériences et l'évaluation de telles expériences
nécessite souvent de faire fonctionner les outils pendant longtemps. De
plus, pour obtenir des résultats statistiquement significatifs, chaque
expérience de configuration doit être répétée au moins 30 fois [6]. Cette
exigence augmente considérablement le temps et les ressources
nécessaires pour mener des expériences SBME.
Les chercheurs de la SBME sont confrontés à au moins deux défis techniques : 1.
Exécuter des expériences à grande échelle de manière efficace, et
2. Comparer les résultats obtenus par différentes exécutions pour différents
algorithmes, outils ou configurations. Pour comparer l'expérience
978-1-7281-5125-0/19/$31,00 ©2019 IEEE
DOI 10.1109/MODELS-C.2019.00032
Steffen Zschaler
Département d'informatique
King's College de Londres
30 Aldwych, Londres, WC2B 4BG
szschaler@acm.org
résultats, les métriques générées par les configurations évaluées
doivent être interprétées et traitées. Cette tâche est souvent effectuée à
l'aide d'un script de traitement de données et nécessite que les données
soient d'abord normalisées afin qu'elles puissent être analysées et
évaluées statistiquement. La plupart des outils SBME utilisent leur
propre standard pour la fréquence et le format des données collectées
au cours des expériences. Cette différence de format de données
nécessite que les chercheurs écrivent leurs propres scripts pour traduire
entre divers schémas et formats de données, en un schéma et un
format communs, afin de traiter les données de l'expérience. Cette
étape de traduction rend le processus lourd et sujet aux erreurs.
Dans cet article, nous proposons MDEOptimiser Scale (MDEO Scale), un
DSL et un framework de distribution de tâches destinés aux outils SMBE.
MDEO Scale permet aux utilisateurs de programmer des expériences SBME
sur des plateformes IaaS, de paralléliser les configurations d'expériences et
de réduire le temps nécessaire à leur exécution. L'outil offre une interface de
collecte de données, qui vise à standardiser le format de collecte des données
des expériences SBME, et offre un support pour le calcul des métriques
d'expérience communes et des statistiques récapitulatives pour les
problèmes de recherche à objectif unique et multi-objectif. Dans cet article,
nous nous concentrons sur les problèmes SBME, cependant, l'approche que
nous décrivons peut être étendue pour prendre en charge l'exécution de
toutes les expériences qui évaluent les techniques de recherche.
Dans cet article, nous apportons les contributions suivantes :
1) nous proposons un DSL qui permet aux utilisateurs de spécifier des configurations
d'expérimentation pour les outils SMBE ;
2) nous décrivons l'architecture d'un framework qui peut exécuter des
expérimentations sur du matériel IaaS ;
3) nous proposons un cadre pour capturer et effectuer une
analyse commune des données d'expérience.
Le reste de cet article est structuré comme suit : Dans la Sect. II nous
introduisons le contexte pertinent. La section IV contient les principales
contributions, décrivant nos motivations, nos objectifs de conception et
l'architecture de nos outils. La section VI décrit la DSL et les détails de
mise en œuvre de notre approche et dans la section VII, nous discutons
des travaux connexes.
II. BRECONNAISSANCE
Dans cette section, nous introduisons des concepts et des définitions qui
sont pertinents pour la recherche décrite dans cet article. Nous donnons des
définitions des termes clés utilisés dans notre DSL, suivies d'une introduction
aux concepts IaaS. Nous présentons ensuite brièvement
189
SBME, suivi d'un aperçu de deux approches SBME
différentes.
A. Infrastructure en tant que service
L'infrastructure en tant que service (IaaS) est un concept utilisé pour décrire les
services qui offrent aux utilisateurs la possibilité de louer du matériel informatique à
la demande, sur Internet. Les services IaaS peuvent évoluer vers le haut et vers le
bas, en fonction des besoins des utilisateurs, et les ressources de calcul utilisées
sont facturées par intervalles de temps fixes, par exemple par heure ou par
seconde. Certains fournisseurs IaaS, en plus des ressources de calcul, proposent
également des services supplémentaires tels que la mise à l'échelle automatique, la
gestion des analyses ou les pipelines d'apprentissage automatique.
Dans cet article, nous utilisons Amazon Web Services1 (AWS) en tant
que fournisseur IaaS. Le produit AWS IaaS offrant des ressources de
calcul s'appelle EC2. Lorsqu'ils utilisent EC2, les utilisateurs peuvent
choisir d'utiliser plusieurs types d'instances, selon le type de location sur
le serveur sous-jacent qu'ils préfèrent. Pour la configuration de notre
outil, nous utilisons des instances Spot EC2, qui sont des instances de
capacité inutilisées de l'inventaire AWS. Les instances EC2 Spot peuvent
être louées à un prix réduit jusqu'à 90 %, une réduction de coût
significative par rapport à l'exécution d'expériences similaires sur des
instances EC2 normales [7]. L'inconvénient de l'utilisation d'instances
Spot EC2 est qu'elles peuvent être arrêtées de manière inattendue dans
les cas où la capacité de calcul inutilisée à partir de laquelle elles sont
générées devient nécessaire pour un autre service IaaS.
Lot AWS2 est un service proposé par AWS, qui permet aux utilisateurs
de planifier des tâches de traitement par lots à exécuter sur
l'infrastructure AWS. Batch, provisionne automatiquement la quantité et
le type optimaux de ressources de calcul et les alloue pour l'exécution
des tâches Batch soumises par l'utilisateur. Les utilisateurs peuvent
interagir avec AWS Batch à l'aide de la AWS Management Console Web
ou de l'API REST AWS.
B. Ingénierie de modèle basée sur la recherche
L'ingénierie des modèles basée sur la recherche est une méthodologie qui
combine des idées d'ingénierie logicielle basée sur la recherche (SBSE) avec
l'ingénierie dirigée par les modèles (MDE). SBSE est une méthodologie qui
applique des algorithmes de recherche méta-heuristiques à des problèmes
de génie logiciel pour trouver des solutions quasi optimales [8]. Pour spécifier
les problèmes SBSE, un certain nombre d'éléments sont nécessaires :
• une représentation de domaine de problème • un procédé pour spécifier des
solutions candidates dans le domaine du problème ; • un ensemble de fonctions de
guidage pouvant indiquer la qualité de la solution • un ensemble d'opérateurs de
recherche pour manipuler les solutions candidates.
SBME est basé sur l'idée que les experts du domaine ont déjà les
problèmes spécifiés dans un langage de modélisation spécifique au domaine,
et utilise des artefacts MDE pour spécifier les problèmes SBSE. Plus
précisément, le domaine du problème est spécifié par le métamodèle, les
solutions candidates sont des modèles d'instance du métamodèle, les
fonctions de guidage sont des requêtes de modèle et les opérateurs de
recherche sont des transformations de modèle.
1http://aws.amazon.com
2http://aws.amazon.com/batch/
190
Deux paradigmes ont été proposés pour résoudre les problèmes
de SBME. Dans cette section, nous allons utiliser deux exemples
d'implémentation.
MDEOptimiser (MDEO) est une approche SBME qui vise à exécuter la
recherche directement sur les modèles, en utilisant les modèles eux-
mêmes comme représentation des solutions candidates [5]. L'espace de
recherche est exploré en appliquant des transformations endogènes
aux modèles de solution et en évaluant la qualité des modèles
résultants à l'aide d'une requête de modèle exprimée en Java ou en OCL.
MOMoT utilise une approche alternative pour spécifier les problèmes
SBME [9]. Dans cette approche, les solutions candidates sont codées sous
forme de chaînes de transformations de modèles appliquées à des modèles
d'entrée de problème. De nouvelles solutions sont générées en appliquant
des mutations et des croisements au vecteur de transformations du modèle,
puis en réappliquant la chaîne de transformations au modèle d'entrée initial
et en évaluant la qualité du modèle de solution obtenu à l'aide d'une requête
de modèle d'une manière similaire à MDEO.
Les deux outils SBME décrits dans cette section utilisent
MOEAFramework 3 pour la mise en œuvre des algorithmes
d'optimisation pris en charge. MOEAFramework est une bibliothèque
basée sur Java, qui offre un certain nombre d'algorithmes à objectif
unique et multi-objectifs ainsi que des fonctionnalités d'instrumentation
et d'évaluation de leurs performances.
Dans cet article, nous démontrons notre DSL à l'échelle MDEO en
utilisant les deux approches SBME présentées dans cette section.
III. RUNNING EXEMPLE
Dans cette section, nous introduisons un exemple de problème
d'optimisation pour montrer comment notre DSL proposé peut être
utilisé pour configurer des expériences en utilisant différents outils
d'optimisation. Le problème de responsabilité de classe (CRA) est une
étude de cas du domaine du génie logiciel [10].
Le but de ce problème est de transformer une application
logicielle implémentée selon une approche procédurale en une
architecture orientée objet tout en trouvant des valeurs optimales
de cohésion et de couplage. La qualité des solutions produites est
mesurée à l'aide de l'indice CRA défini dans [10], comme objectif
unique. Le problème fournit un graphe de dépendance de
responsabilité, qui contient un ensemble de fonctions et d'attributs
avec des dépendances entre eux. Dans le métamodèle, ces entités
sont des instances de type abstrait Feature.
Pour résoudre ce problème, l'utilisateur doit créer Classer
entités dans le Modèle de classe et attribuer Caractéristiques à eux de
telle sorte que : tous Caractéristiques sont affectés à un Classer et le
modèle avec la valeur d'indice CRA la plus élevée est trouvé. Le
problème a une contrainte supplémentaire exigeant que chaque
caractéristique soit affectée à un seulClasser à la fois.
IV. LCONCEPTION D'ANGLE ET D'INFRASTRUCTURE
Dans cette section, nous présentons la motivation pour développer
l'outil MDEO Scale. Nous continuons ensuite à énumérer les objectifs de
conception et à donner un aperçu de l'architecture prototype proposée
et de l'infrastructure prise en charge.
3http://moeaframework.org/
A. Définitions TABLEAU I
SRÉSUMÉ DES STATISTIQUES RÉSUMÉ GÉNÉRÉES POUR LES
Dans cet article, nous utilisons les termes suivants pour décrire notre MULTI-O EXPÉRIENCES BJECTIVES.

DSL proposée :
Objectif unique Multi-Objectif
UNE Tâche fait référence à une seule instance de problème exécutable, Étapes de l'algorithme Étapes de l'algorithme

avec des entrées préconfigurées. Un exemple deTâche exécuterait un outil Moyenne objective Moyenne de l'hypervolume
Médiane objective Médiane d'hypervolume
SBME, pour un modèle d'entrée spécifique à partir d'une étude de cas évaluée.
Objectif Minimum Hypervolume minimum
Objectif Maximum Hypervolume maximum
UNE Grouper désigne une seule exécution d'un Tâche. Lors de l'évaluation Écart-type objectif Asymétrie Écart-type de l'hypervolume
d'études de cas à l'aide d'outils SBME utilisant des algorithmes objectif Incidence de l'hypervolume
Kurtosis objectif Kurtose hypervolumique
métaheuristiques, Tâches sont généralement exécutés plusieurs fois, pour
N/A Taille de l'ensemble de référence

garantir que les résultats obtenus sont statistiquement significatifs. Chaque N/A Ensemble de référence Contributions

Tâche l'exécution compte comme une grouper. N/A Ratio des meilleures solutions

Un Expérience fait référence à une étude de cas pour laquelle un

effet doit être évalué à l'aide d'un ensemble de tâches ayant différentes
entrées de configuration. Chaque expérience peut contenir un nombre
quelconque de modèles d'entrée, etTâches sont regroupés selon le
modèle d'entrée qu'ils évaluent.

B. Motivation et cas d'utilisation

La motivation pour la mise en œuvre de l'échelle MDEO est venue de la

nécessité d'exécuter des expériences SBME en utilisant plusieurs outils et
configurations tout en réduisant le temps d'attente pour que les résultats
soient prêts et en étant capable d'interpréter facilement les résultats.
Lors de l'évaluation des travaux publiés dans [3], les auteurs ont Fig. 1. Résumé de l'architecture DSL de MDEOptimiser Scale montrant les principaux
exécuté 498 configurations à l'aide de trois outils qui ont nécessité composants de l'outil

plus de 2500 heures d'exécution MDEO. L'exécution de ces

expériences sur une seule machine a nécessité plus de 100 jours
d'exécution continue. En parallélisant les tâches d'expérimentation
à l'aide d'AWS Batch, les auteurs ont pu réduire le temps total
requis pour exécuter les expérimentations à moins de 5 jours.
Un autre problème lié à l'exécution d'un grand nombre de
configurations d'expériences est de conserver un journal d'audit des
expériences qui ont été exécutées, sur quel type de matériel et quelles
métriques correspondent à un lot d'expériences spécifique. De plus, un
grand nombre de configurations expérimentales génèrent un grand
nombre de fichiers de résultats. Lors de l'exécution de la même
expérience avec plusieurs outils, l'étape de traitement des données doit
aligner les sorties de l'outil pour s'assurer que les fichiers de résultats
sont dans le même format et que les valeurs correctes sont comparées.
C. Objectifs de conception
Dans cette section, nous décrivons les objectifs de conception de
l'échelle MDEO DSL. Notre DSL vise à satisfaire les exigences
suivantes :
D. Architecture
Cette section présente l'architecture de l'outil MDEO Scale, un
DSL qui aide les utilisateurs à configurer et à déployer des
expériences SBME sur du matériel IaaS.
Dans la figure 1, nous incluons une vue d'ensemble de l'architecture
de l'outil. Le DSL orienté utilisateur est implémenté à l'aide de XText.
L'outil contient cinq composants principaux, qui seront décrits dans les
sections suivantes.
1) Interprète DSL : Les composants de l'interpréteur DSL se chargent
le DSL spécifié par l'utilisateur et vérifie la cohérence des entrées
utilisateur. L'utilisateur est averti si l'un des fichiers de configuration
spécifiés ou leurs dépendances n'ont pas pu être trouvés aux
emplacements spécifiés.
2) Générateur de tâches : Le composant générateur de tâches crée
instances de tâche pour chaque tâche configurée par l'utilisateur dans le DSL.
Chaque tâche est associée à l'implémentation de l'outil correspondant, en fonction
des entrées de l'utilisateur.
3) Planificateur de tâches : Le composant du planificateur de tâches se charge

1) Offrir un DSL basé sur du texte pour spécifier les expériences
SBME ;
2) Nécessite une configuration et une installation minimales de l'utilisateur ;
3) Fournir un cadre extensible qui facilite l'ajout de nouveaux outils et
un support matériel supplémentaire pour l'exécution
d'expériences automatisées ;
4) Proposer une interface commune pour collecter les métriques
d'expérimentation à partir des outils SBME ;
5) Offrir un support pour interpréter automatiquement les métriques
d'expérience à l'aide de métriques statistiques courantes.
les tâches générées et les envoie au fournisseur d'infrastructure
pour exécution. Ce composant fournit également des informations
d'état pour les tâches qui ont été planifiées.
4) Fournisseur d'infrastructure : Ce composant implémente
l'API du fournisseur IaaS. Il fournit une interface pour envoyer les tâches
configurées à la file d'attente d'exécution des tâches.
5) Analyseur de résultats : Le composant analyseur de résultats est
utilisé dans l'échelle MDEO pour calculer automatiquement les statistiques
récapitulatives et les métriques communes pour les expériences configurées.
L'évaluation de la qualité de la solution pour les op-

191

Fig. 2. Présentation de l'infrastructure AWS Batch.
les problèmes de timisation sont simples. Cependant, pour les problèmes
multi-objectifs, l'évaluation de la qualité de la solution n'est pas un problème
trivial et un certain nombre d'indicateurs de qualité de la solution ont été
proposés pour simplifier cette tâche [11].
L'échelle MDEO détermine automatiquement si un problème résolu
dans une expérience a un ou plusieurs objectifs. Selon le nombre
d'objectifs, les statistiques récapitulatives incluses dans le tableau I sont
calculées pour chaque instance de modèle de problème spécifiée. Les
statistiques calculées ont été mises en œuvre sur la base des exigences
d'évaluation des performances des problèmes de recherche à objectif
unique et multi-objectifs de l'auteur [3]–[5]. Le cadre d'évaluation des
résultats peut être étendu pour ajouter un support supplémentaire
pour des indicateurs de qualité supplémentaires et des calculs
d'évaluation statistique. Pour les problèmes à objectif unique, les
résumés des résultats sont calculés en utilisant la valeur de l'objectif.
Pour les problèmes multi-objectifs, l'outil utilise l'indicateur de qualité
hypervolume [12].
Pour chaque modèle d'instance de problème, l'outil effectue également
des tests de signification statistique à l'aide du test U de Mann-Whiney [13] et
calcule la taille d'effet d de Cohen [14]. L'outil génère une tâche d'analyse des
résultats pour chaque expérience définie par l'utilisateur dans le DSL. Pour
garantir que les métriques collectées sont disponibles avant le début de
l'analyse des résultats, les tâches d'analyse des résultats dépendent de la
réussite des principales tâches d'expérimentation.
E. Infrastructures
Dans cette section, nous décrivons comment MDEO Scale déploie les
tâches SBME configurées sur l'infrastructure AWS. Nous montrons
comment l'outil utilise des services supplémentaires offerts par AWS
pour stocker les métriques et expérimenter les artefacts nécessaires aux
tâches orchestrées.
le Fournisseur d'infrastructures Le composant décrit dans la section
précédente offre une interface vers l'infrastructure IaaS fournie par AWS
Batch. Dans la figure 2, nous incluons une vue d'ensemble de haut
niveau de l'architecture AWS Batch. Le service repose sur une file
d'attente de messagerie, qui accepte les demandes de travail qui
doivent être exécutées. La file d'attente est connectée à un
Environnement de calcul qui définit le type de ressources de calcul
pouvant être utilisées pour traiter les tâches en file d'attente. Selon le
type de ressources de calcul configurées, le planificateur AWS Batch
peut exécuter les tâches soumises immédiatement, ou il
192
attendra jusqu'à ce que le type de ressources de calcul requis soit
disponible.
Dans la version actuelle du DSL, les utilisateurs configurent le
Environnement de calcul en utilisant le environnement mot-clé dans le
Infrastructure bloc de la DSL. Les serveurs traitant les tâches
interagissent avec le système de stockage S3 pour récupérer les
artefacts requis pour letâche et de publier les résultats de sortie.
Les résultats de sortie sont traités par leTâches programmé par le
Analyseur de résultats composant.
F. Interface de collecte de données
Dans cette section, nous présentons l'interface de collecte de
données utilisée par MDEO Scale lors de l'exécution d'expériences avec
les outils SBME. La version actuelle de MDEO Scale se concentre sur
l'exécution d'expériences SBME avec les deux outils introduits dans Sect.
II. MDEO et MOMoT sont tous deux implémentés à l'aide du
MOEAFramework, qui fournit une interface pour collecter des métriques
à des fins d'analyse. Nous avons utilisé cette interface et le format de
données proposé dans notre composante d'analyse des résultats.
L'interface de collecte de données dans MOEAFramework est décrite
dans le org.moeaframework.analysis.collector 4
paquet. Pour assurer la compatibilité avec l'analyseur de résultats
dans MDEO Scale, des outils supplémentaires pris en charge
doivent générer des résultats d'expérimentation dans le format
spécifié par l'interface de collecte de données implémentée dans
MOEAFramework.
V. JeMISE EN OEUVRE
Dans cette section, nous donnons un aperçu du DSL implémenté
dans notre outil, suivi de détails sur l'implémentation et la pile
technologique utilisée pour l'implémentation. Nous commençons par
décrire le DSL à l'aide d'un exemple d'étude de cas. Nous donnons
ensuite un aperçu de la structure de l'outil et des points d'extension qui
peuvent être utilisés pour implémenter la prise en charge d'outils SBME
et de fournisseurs d'infrastructure supplémentaires. L'implémentation
décrite dans cette section peut être trouvée sur Github5.
A. DSL
Dans la figure 3, nous incluons un exemple de spécification pour l'étude de
cas Class Responsibility Assignment [10] (CRA) qui montre comment utiliser
notre DSL pour configurer un flux de travail d'expérimentation qui exécute
MDEO et MOMoT pour les deux premiers modèles d'entrée de l'étude de cas.
Une spécification d'échelle MDEOptimiser comporte deux sections
obligatoires qui doivent être spécifiées par les utilisateurs. La première
section, définie par leInfrastructure Le mot-clé définit les détails de la
configuration IaaS. Les détails de configuration obligatoires sont le type
de fournisseur d'infrastructure (actuellement, seul AWS est pris en
charge), le nom du compte qui est configuré sur la machine exécutant le
DSL et un modèle d'environnement de calcul6, qui définit les types de
ressources de calcul, qui seront utilisées par l'outil pour orchestrer les
tâches d'expérimentation.
4http://moeaframework.org/javadoc/org/moeaframework/analysis/collector/
package-summary.html
5https://github.com/mde-optimiser/scale
6https://docs.aws.amazon.com/cli/latest/reference/batch/
create-compute-environment.html

Fig. 3. Exemple MDEOptimiser Scale DSL montrant une expérience configurée pour
l'étude de cas CRA avec deux modèles d'entrée. Chaque modèle d'entrée est évalué
avec MDEO et MoMOT.
La section suivante est définie par le expérience mot-clé. Ce bloc
est utilisé pour définir le flux de travail de l'expérimentation,
organisé par l'étude de cas évaluée et les modèles d'entrée qui
doivent être évalués. leexpérience Le mot-clé nécessite la
spécification d'un paramètre de nom. Cette valeur sera utilisée
comme identifiant unique pour l'expérience, et l'outil utilise cette
valeur pour marquer les composants sous-jacents.
Pour chaque expérience, la DSL permet aux utilisateurs de spécifier un
ensemble de paramètres qui sont appliqués à toutes les tâches enfants. Les
deux paramètres pris en charge sontlots, pour définir le nombre de
tâche répétitions, et le artefacts paramètre pour indiquer l'emplacement
du disque qui contient tous les artefacts d'étude de cas utilisés par les
spécifications de tâche chargées par le Cours mot-clé.
Chaque expérience nécessite qu'au moins un modèle d'entrée
soit spécifié à l'aide de la maquette mot-clé. De même au
expérience mot-clé, maquette exige également que l'utilisateur
spécifie un nom pour le modèle en cours d'évaluation.
A l'intérieur de chaque maquette bloc, le DSL nécessite au moins un
tâche à préciser. UNEtâche définit une configuration unique pour
un outil SBME, qui peut être utilisé pour évaluer une configuration
spécifique pour le modèle d'entrée de l'étude de cas, pour lequel il
a été spécifié. Actuellement, le DSL ne prend en charge que le
193
Fig. 4. Mode autonome de MDEOptimiser Scale. Cette figure montre le menu d'aide imprimé
affiché lors de l'exécution de l'outil à partir de la ligne de commande.
deux outils décrits dans la section II.
Une spécification complète doit être écrite dans un fichier avec le
sc extension. Le défini par l'utilisateursc Les fichiers peuvent être exécutés à
l'aide de l'outil en tant que plug-in Eclipse, depuis l'IDE Eclipse ou en utilisant
le mode autonome à partir de la ligne de commande. Dans la figure 4, nous
incluons les instructions autonomes de l'outil. Cette fonctionnalité est utile
lors de l'exécution de MDEO Scale en dehors d'Eclipse IDE.
B. Extensibilité
Dans cette section, nous décrivons comment l'échelle MDEO peut être étendue pour
prendre en charge des outils supplémentaires.
Pour mettre en œuvre des outils supplémentaires, les utilisateurs doivent mettre en œuvre le
IScaleTâche interface et enregistrez la classe d'extension dans le
TaskFactory. Les outils sont instanciés par le Usine de tâches
en utilisant l'extension du fichier de spécification SBME spécifié par
le Cours mot-clé dans le DSL. Pour chaque tâche configurée par
l'utilisateur dans le DSL, une nouvelle classe d'instance d'outil est
créée avec les paramètres fournis par l'utilisateur.IScaleTâche les
implémentations de nouvelles tâches doivent fournir un conteneur
Docker avec une instance configurée du nouvel outil à l'aide du
service wrapper d'exécution d'outil MDEO Scale implémenté dans le
OutilExécuteur classer. Le service d'encapsuleur d'outil garantit que le
conteneur Docker configuré pour chaque outil peut interpréter les
messages de spécification de tâche DSL reçus de la file d'attente AWS
Batch. Le conteneur doit être publié sur le Docker Hub. Les images de
conteneurs stockées dans des référentiels privés ne sont actuellement
pas prises en charge.
La version actuelle de l'outil repose largement sur le service AWS Batch.
L'outil peut être étendu pour prendre en charge des fournisseurs IaaS
supplémentaires en implémentant des fournisseurs supplémentaires dans le
composant d'approvisionnement d'infrastructure.
VI. EXEMPLE RONU
Dans cette section, nous décrivons une exécution démonstrative de
l'échelle MDEO en utilisant la configuration DSL décrite en 3. Cet
exemple d'exécution utilise l'étude de cas introduite en III spécifiée en
utilisant MDEO et MoMOT. L'étude de cas se compose de cinq modèles
d'entrée, cependant, en raison des limitations d'espace, pour cette
démonstration, seuls les modèles d'entrée A et B seront utilisés. Une
évaluation complète de cette étude de cas utilisant les deux outils
utilisés dans cette configuration peut être trouvée dans [4].
En exécutant l'outil à l'aide de la spécification de la figure 3,
MDEO Scale génère 120 tâches AWS Batch pour les tâches
spécifiées. Une tâche individuelle est générée pour chaque
exécution par lots des tâches configurées. Suite à la planification
des messages de tâches dans la file d'attente, AWS Batch Scheduler
détermine et initialise automatiquement le nombre optimal de
serveurs à initialiser pour le traitement des tâches
de la file d'attente. Le traitement peut commencer immédiatement
ou avec un délai, selon la configuration spécifiée à l'aide de la
Infrastructure bloquer dans le DSL. Une fois les serveurs de traitement
disponibles, le traitement des travaux commence en parallèle, jusqu'à
ce que la file d'attente soit vidée. À la fin de chaque lot, les fichiers de
résultats générés sont enregistrés et téléchargés sur AWS S3 pour être
traités par l'analyseur de résultats.
L'analyseur de résultats est exécuté une fois que toutes les tâches de file
d'attente AWS Batch ont été traitées avec succès et que les artefacts de
résultats sont disponibles pour le traitement dans AWS S3. Les fichiers de
résultats générés pour chaque tâche traitée sont chargés par l'outil à partir
d'AWS S3 et les fichiers générés sont traités pour calculer les métriques
décrites dans le tableau I. Pour chaquemaquette l'analyseur de résultats
génère un graphique montrant l'évolution de la valeur de l'objectif pour les
problèmes à objectif unique et de l'hypervolume pour les problèmes à
objectifs multiples.
VII. RTRAVAIL ÉLEVÉ
Récemment, un certain nombre d'outils ont été développés dans
le but d'aider les chercheurs à configurer et à exécuter des
expériences, d'une manière qui détourne l'attention de la création
de logiciels d'orchestration et rend le processus reproductible.
[15]. Alors que la plupart de ces systèmes sont destinés à des domaines
à forte intensité de données, tels que les sciences de la vie et
l'astronomie, à notre connaissance, aucun outil de ce type ne prend en
charge les outils SMBE.
A. Déploiement Cloud
L'Open Cloud Computing Interface (OCCI) est une spécification
qui propose un standard commun pour interagir avec les
ressources de calcul offertes par les fournisseurs IaaS, PaaS [16].
L'OCCI a été proposé par leForum de grille ouverte et consiste en
une spécification d'API qui cherche à normaliser la façon dont les
utilisateurs interagissent avec les API fournies par différents
fournisseurs XaaS. Une autre norme de spécification est la
spécification de topologie et d'orchestration pour les applications
cloud (TOSCA) [17].
Dans [18] Erbel et al. proposer une approche qui peut planifier des
architectures de flux de travail à exécuter sur une infrastructure cloud à l'aide
d'OCCI. Cette approche vise à s'exécuter sur des clouds compatibles OCCI et à
maximiser l'utilisation des ressources pour les nœuds de calcul provisionnés,
en exécutant une simulation pour évaluer les métriques de performance
avant qu'un déploiement ne soit effectué.
Une approche similaire pour reproduire des workflows scientifiques
sur le cloud, en utilisant TOSCA, est proposée dans Qasha et al. dans
[19]. Les auteurs proposent un framework qui vise à utiliser Github et
DockerHub7 en tant que référentiels pour stocker les flux de travail et les
tâches. Ce framework utilise Cloudify8 en tant que moteur de flux de
travail conforme TOSCA.
Notre approche est similaire aux deux cadres décrits dans cette
section. La principale différence est que MDEOptimiser Scale s'adresse à
la communauté SBME et offre un certain nombre d'outils
supplémentaires, tels que la collecte de métriques et la génération de
résumés de résultats. En utilisant l'un des deux frameworks ci-dessus,
7https://www.docker.com/products/docker-hub
8https://cloudify.co/
194
les utilisateurs doivent encore résoudre le problème de la capture des données
d'expérience et de leur interprétation.
B. Traitement par lots
Les outils de traitement par lots sont des applications capables de traiter
des tâches à forte intensité de calcul de manière séquentielle ou parallèle, sur
un seul serveur ou sur un cluster de serveurs.
Apache Mesos est un framework de planification de tâches distribué
qui permet aux tâches d'être exécutées sur un cluster de serveurs [20].
L'objectif de Mesos est d'offrir une bonne utilisation des ressources,
tout en s'adaptant à des milliers de nœuds dans un cluster de serveurs,
tout en prenant en charge un grand nombre de tâches à planifier et à
exécuter. Les tâches sont isolées à l'aide de technologies de conteneurs,
telles que Docker ou une implémentation de conteneurisation intégrée.
Un autre cadre d'ordonnancement des tâches est Bistro [21]. Bistro est un
planificateur de tâches distribué, qui exécute des tâches gourmandes en
données sur des systèmes de production en direct qui ont une capacité de
calcul inutilisée. L'objectif de ce planificateur est de traiter les données au
moment de l'exécution, sans avoir à créer une sauvegarde immuable. L'outil
utilise un algorithme de planification des tâches pour attribuer des tâches aux
travailleurs et peut traiter les tâches sans affecter les performances des
applications en direct destinées aux clients.
Luigi est un orchestrateur de pipelines de tâches par lots implémenté à
l'aide de Python [22]. L'outil offre des fonctionnalités permettant de visualiser
l'état des travaux par lots en cours d'exécution, de gérer les échecs et de
gérer les flux de travail. Les tâches sont exécutées à l'aide d'un planificateur,
qui peut être local, pour les tâches exécutées localement, ou central pour les
tâches réparties sur un certain nombre de travailleurs exécutant des tâches.
Cet outil n'est pas aussi complexe que Mesos ou Bistro, cependant, c'est un
bon exemple d'outil de planification de tâches simple qui peut être utilisé
pour gérer des flux de travail simples.
Notre DSL peut être étendu pour prendre en charge en tant que
technologies de traitement par lots l'un des outils présentés dans
cette section. L'inconvénient lié à l'utilisation de Mesos ou Bistro
comme backend est qu'il y a une surcharge initiale requise pour
configurer ces outils afin qu'ils puissent être utilisés. Cette option
est viable lorsqu'un cluster de serveurs existant est disponible, qui
n'a pas de structure d'orchestration de ressources déployée. Notre
approche utilise du matériel IaaS, fourni par AWS et élimine la
nécessité de posséder et de maintenir un cluster.
C. Workflows d'expérimentation
Les systèmes de flux de travail d'expérimentation sont des outils de calcul qui
permettent aux chercheurs qui effectuent des expériences gourmandes en données
de se concentrer sur leur travail au lieu de créer des pipelines de traitement de
données. Ces outils sont axés sur des domaines de recherche à forte intensité de
données tels que la bioinformatique, la chimie ou la physique. Une liste organisée
des systèmes de flux de travail existants peut être consultée dans [23].
Common Workflow Language (CWL) est une norme de spécification de
workflow [24]. CWL peut être utilisé pour créer des workflows d'analyse
portables. Les workflows basés sur CWL se composent d'outils de ligne de
commande orchestrés, qui peuvent s'exécuter sur des plates-formes qui
implémentent la norme. Un autre flux de travail de pipeline de calcul DSL est
Nextflow [25]. L'outil permet aux utilisateurs d'utiliser des langages de script
exécutables Linux pour définir des processus qui peuvent
être orchestré pour former un pipeline. Netflow prend en charge par
défaut Google Computing Cloud et Amazon Web Services.
Le DSL que nous avons présenté dans cet article peut être étendu pour
générer des instances de workflow CWL ou NextFlow. Cela nous permettra
d'étendre le nombre de plates-formes de déploiement prises en charge tout
en nous concentrant sur les besoins des praticiens SBME qui utilisent notre
DSL et en utilisant un moteur de flux de travail plus mature comme backend
pour la gestion de notre architecture de flux de travail.
VIII. CINCLUSION ET FAVENIR WORK
Dans cet article, nous avons présenté un prototype du MDEO Scale
DSL, un outil qui permet aux chercheurs exécutant des expériences à
l'aide des outils SBME de créer facilement un flux de travail d'expérience
pouvant être exécuté sur du matériel IaaS. L'outil offre une approche
accessible pour partager les flux de travail des expériences SBME, afin
de faciliter la publication d'artefacts de recherche reproductibles. Nous
avons décrit nos motivations pour construire l'outil et donné un aperçu
de l'architecture et de l'approche utilisée pour orchestrer les
expérimentations sur le matériel Iaas.
L'outil présenté dans cet article est un prototype aux
premiers stades de développement. À l'avenir, nous prévoyons
d'étendre l'outil dans un certain nombre de directions. Voici
une liste d'idées en cours d'évaluation :
• Étendre la prise en charge de plusieurs fournisseurs IaaS ;
• Améliorer l'extensibilité du DSL en permettant aux utilisateurs d'ajouter la
prise en charge d'outils supplémentaires en spécifiant simplement dans le
DSL une classe implémentant une interface pour prendre en charge des
outils supplémentaires ;
• Autoriser les utilisateurs à spécifier des métriques personnalisées qui peuvent être
calculées sur les métriques générées ;
• Offrir la possibilité de charger facilement des études de cas à partir
d'un pool pris en charge par l'outil pour faciliter l'évaluation des idées
de recherche SBME ;
• Évaluer les menaces de reproductibilité des expériences et les
stratégies d'atténuation lors de l'utilisation de matériel cloud ;
• Étendre le DSL pour prendre en charge l'exécution des outils et
des problèmes du domaine plus large de SBSE ;
• Étendez la fonctionnalité d'instrumentation de l'algorithme
pour simplifier l'intégration avec des cadres d'optimisation
autres que MOEAFramework.
UNERECONNAISSANCE
Ce travail a été soutenu par le Conseil de recherche en
génie et en sciences physiques numéro d'octroi 1805606.
RÉFÉRENCES
[1] I. Boussa¨ı̈d, P. Siarry et M. Ahmed-Nacer, « A survey on search-based
model-driven engineering », Génie logiciel automatisé, vol. 24, non. 2, p.
233-294, 2017.
[2] D. Efstathiou, JR Williams et S. Zschaler, « Crêpe complète : optimisation multi-
objectifs pour vos modèles », dans Proc. 1er atelier international sur la
combinaison de la modélisation avec des approches basées sur la recherche
et l'exemple (CMSEBA'14),2014.
[3] J. Murphy, A. Burdusel, L. Michael, S. Zschaler et E. Black, « Deriving
persuasion strategies using search-based model engineering », dans
Modèles informatiques d'argumentation : Actes de COMMA 2018, vol.
305, p. 221-232, IOS Press, 2018.
195
[4] S. John, A. Burdusel, R. Bill, D. Struber, G. Taentzer, S. Zschaler et
M. Wimmer, « Recherche de modèles optimaux : comparaison de deux
approches d'encodage », dans Théorie et pratique de la transformation de
modèle : 12e conférence internationale, acceptée, ICMT '19, 2019.
[5] A. Burdusel, S. Zschaler et S. John, « Génération automatique d'opérateurs de recherche
préservant la cohérence atomique pour l'ingénierie des modèles basés sur la
recherche », dans IEEE / ACM 22e conférence internationale sur les langages et
systèmes d'ingénierie pilotés par les modèles, MODÈLES, 2019.
[6] A. Arcuri et L. Briand, « A hitchhiker's guide to statistics tests for
evaluation randomised algorithms in software engineering », Tests,
vérification et fiabilité des logiciels, vol. 24, non. 3, p. 219-250, 2014.
[7] P. Fazenda, J. McDermott et U.-M. O'Reilly, « A library to run evolutionary
algorithms in the cloud using mapreduce », dansConférence
européenne sur les applications du calcul évolutif, p. 416–
425, 2012.
[8] M. Harman, SA Mansouri et Y. Zhang, « Ingénierie logicielle basée sur la
recherche : tendances, techniques et applications », Calcul ACM. Surv.,
vol. 45, non. 1, pages 11 : 1-11 : 61, 2012.
[9] R. Bill, M. Fleck, J. Troya, T. Mayerhofer et M. Wimmer, « A local and global
tour on MOMoT », Modélisation de logiciels et de systèmes, p. 1-30,
2017.
[10] M. Fleck, J. Troya et M. Wimmer, « The class responsa- bilité assignation
case », dans Actes du 9e concours d'outils de transformation
(A. Garcia-Dominguez, F. Krikava et LM Rose, éd.), vol. 1758, p. 1-8,
CEUR, 2016.
[11] M. Li et X. Yao, « Evaluation de la qualité des ensembles de solutions en optimisation
multiobjectif : une enquête », Enquêtes informatiques ACM (CSUR), vol. 52, non. 2, p.
26, 2019.
[12] E. Zitzler, D. Brockhoff et L. Thiele, « L'indicateur d'hypervolume revisité :
sur la conception d'indicateurs conformes à Pareto via une intégration
pondérée », dans Optimisation multicritère évolutive, p. 862-876,
2007.
[13] HB Mann et DR Whitney, « Sur un test pour savoir si l'une des deux
variables aléatoires est stochastiquement plus grande que l'autre »,
Anne. Math. Statist.,vol. 18, p. 50-60, 03 1947.
[14] J. Cohen, « Analyse de puissance statistique pour la science du comportement. (2e) »,
New Jersey : Laurence Erlbaum Associates, Publishers, Hillsdale, 1988.
[15] J. Liu, E. Pacitti, P. Valduriez et M. Mattoso, « A survey of data-intensive
scientific workflow management », Journal de l'informatique en grille,
vol. 13, p. 457-493, décembre 2015.
[16] A. Edmonds, T. Metsch, A. Papaspyrou et A. Richardson, « Toward an
open cloud standard », Informatique Internet IEEE, vol. 16, non. 4, p. 15–
25, 2012.
[17] « Spécification de topologie et d'orchestration OASIS pour les applications
cloud ». https://www.oasis-open.org/committees/tc home.php?wg
abbrev=tosca. Consulté le : 2019-07-04.
[18] J. Erbel, F. Korte et J. Grabowski, « Scheduling architectures for scientific
workflows in the cloud », dans Analyse et modélisation du système.
Langages, méthodes et outils pour l'ingénierie des systèmes,p. 20-28,
2018.
[19] R. Qasha, J. Cała et P. Watson, « A framework for scientific workflow
reproductibility in the cloud », dans 2016 IEEE 12th International
Conference on e-Science (e-Science), p. 81-90, IEEE, 2016.
[20] B. Hindman, A. Konwinski, M. Zaharia, A. Ghodsi, AD Joseph, RH Katz, S.
Shenker et I. Stoica, « Mesos : A platform for fine-grained resources
sharing in the data center. ," dans NSDI, vol. 11, p. 22-22, 2011.
[21] A. Goder, A. Spiridonov et Y. Wang, « Bistro : Scheduling data-parallel jobs
against live production systems », dans Conférence technique annuelle
{USENIX} 2015 ({USENIX}{ATC} 15), p. 459-471, 2015.
[22] "Luigi". https://github.com/spotify/luigi. Consulté le : 2019-07-04.
[23] « Systèmes de flux de travail pour l'analyse de données informatiques ». https://
s.apache.org/existing-workflow-systems. Consulté le : 2019-07-04.
[24] P. Amstutz, MR Crusoe, N. Tijanić, B. Chapman, J. Chilton, M. Heuer,
A. Kartashov, D. Leehr, H. Ménager, M. Nedeljkovich, M. Scales,
S. Soiland-Reyes et L. Stojanovic, « Common Workflow Language, v1.0 »,
7 2016.
[25] « NextFlow a dsl pour un pipeline de calcul parallèle et évolutif. » https : //
www.nextflow.io/. Consulté le : 2019-07-04.