Examen IDM 2012 (16.11.2012, 15:45 – 17:45)

Examen IDM 2012 (16.11.2012, 15:45 – 17:45) Seuls les documents papier sont autorisés. Barème donné à titre indicatif. Cas d’étude : « Workflows Scientifique » Un workflow est un ensemble de tâches permettant de traiter un gros volume de données. Ces tâches sont exécutées sur une infrastructure distribuée parallèle (par ex. grille de calcul, cloud) pour en optimiser l’exécution. Dans le domaine de la santé publique par exemple, l’idée clé est de confronter les examens médicaux passés par les patients à des analyses plus poussés (donc plus longue), en utilisant la puissance d’une infrastructure de calcul distribuée pour analyser ces documents avec plus de zèle qu’un simple examen de routine. Les pathologies latentes sont ainsi identifiées à un stade précoce de leur développement et il devient possible d’anticiper leur traitement. Des exemples typiques sont (i) l’analyse d’images IRM du cerveau pour détecter des cas précoces de dégénérescence neuronale, ou encore (ii) l’analyse d’échographies cardiaques pour identifier des problèmes cardio-­‐vasculaires latents. Dans le domaine de la biologie on rencontre des problématiques de séquençage d’ADN, ou encore de « docking moléculaire » pour les expérimentation de médicament in silico, demandant une grande puissance de calcul. De nombreux langages permettant d’exprimer des workflows existent dans l’état de l’art1. Ici, nous travaillerons sur un sous-­‐ensemble du langage GWENDIA et de son interpréteur Moteur22, co-­‐développés par l’équipe MODALIS du laboratoire I3S, et largement utilisés par la communauté scientifique depuis leur création en 2007. Exemple #1 : Traitement séquentiel des données. Un workflow travaille sur un ensemble de données d’entrées, délivrées par des sources. Une source correspond à une collection ordonnée de données (c.à.d. un tableau), qui peuvent être de type « chaine de caractères », « nombre entier » ou « nombre flottant ». Les résultats du calcul du workflow sont stockés dans des puits. Pour traiter les données, le workflow définit des processeurs, qui définissent un ensemble d’entrées et de sorties (typées). Les processeurs traitant les données sont implémentés par des « bean shells » (i.e., des script java, donnés sous forme de chaine de caractères). Des liens sont utilisés pour relier sources, entrées, sorties et puits, mettant en œuvre un flot de donnée réalisant le traitement souhaité. 1 Voir par exemple http://www.myexperiment.org/, un réseau social d’échange de workflow entre scientifiques du monde entier. 2 Tristan Glatard, Johan Montagnat, Diane Lingrand, Xavier Pennec. “Flexible and Efficient Workflow Deployement of Data-­‐Intensive Applications on Grids with MOTEUR”, International Journal of High Performance Computing Application, pages 347-­‐360, 2008 x: int
a: int
add1
b=a+1
...
b: int
source
processor
sink
input
"beanshell"
link
legend
xP: int
output
Figure 1 -­‐ Workflow séquentiel. La figure 1 représente un workflow ayant une source nommée « x » de type entier, et un puits nommé « xP », lui aussi de type entier. Il définit un processeur nommé « add1 », ayant une entrée « a » de type entier, et une sortie « b » de type entier. Ce processeur exécute le code java « b = a + 1 » à chaque exécution. Le moteur de workflow transfère chaque élément de la collection « x » sur l’entrée « a » du processeur « add1 » (lien « x ⇒ add1:a »), puis chaque résultat d’exécution (lus sur la sortie « b ») est déposé dans le puits « xP » (lien « add1:b ⇒ xP »). Ainsi, si l’utilisateur fournit une collection [2, 4, 6] pour « x », le moteur exécutera 3 fois le processeur « add1 » (potentiellement sur 3 nœuds de calcul différents, si disponibles), et agrègera les résultats de chaque invocation dans une collection récupérable dans « xP » (c.à.d. [3, 5, 7]). Pour tout résultat d’exécution, il est possible de savoir quelles sont la ou les données sources ayant conduit à ce résultat (ici, xP[0] a été produit à partir de x[0], …). Exemple #2 : Corrélation et croisement de données. Les processeurs peuvent prendre en entrée plusieurs données. Dans ce cas, il convient d’expliciter au moteur comment les données doivent être composées. On distingue 2 types de compositions utilisables : (i) la corrélation (dénotée par un point) et (ii) le croisement (dénoté par une croix). x: int y: int
z= x + y
⊙
x: int y: int
⊗
adder
adder
z: int
z: int
z= x + y
Figure 2 -­‐ Opérateurs de composition de données : corrélation et croisement. Considérons ici les 2 processeurs « adder » représentés en Figure 2. Ils reçoivent en entrée deux entiers, et produisent en sortie leur addition. Celui de gauche utilise une corrélation, et celui de droite un croisement. On considère maintenant les 2 collections de données suivantes : [1, 2, 3] et [8, 9]. En corrélant ces données sur ses entrées « x » et « y », le processeur de gauche produira sur « z » les résultats suivants : 9 (=1+8), 11 (=2+9) et la valeur nulle « ? » (=3+?). En croisant ces donnés, le processeur de droite utilisera toutes les combinaisons possibles pour « x » et « y » et produira les résultats suivants : 9 (=1+8), 10 (=2+8), 11 (=3+8), 10 (=1+9), 11 (=2+9), 12 (=3+9). val: int
factor: int
y: int
x: int
⊙
z= x * y
mult
z: int
z= x * y
x: int
y: int
⊗
mult2
z: int
square: int
fsquared: int
Figure 3 -­‐ Composition de données La figure 3 montre comment ces mécanismes sont utilisables sur un workflow plus conséquent. Ce workflow définit deux sources entières : « val » et « factor ». Sur cette base, il calcule dans le puits « square » les carrés de « val », et dans le puits « fsquared » les carrés de « val » multipliés par chaque « factor ». Ainsi, si « val » contient les données [1, 2, 3] et « factor » les données [10, 100] : • square = [1, 4, 9] • fsquared = [10, 40, 90, 100, 400, 900] Exemple #3 : Filtrage & Traitement conditionnel des données. Deux processeurs particuliers existent dans le domaine : (i) les aiguillages et (ii) les filtres. Le rôle d’un aiguillage est de définir une condition (une expression Java sur sa donnée en entrée, donnée sous la forme d’une chaine de caractères), et de router automatiquement sur ses sorties « ok » et « ko » les donnés validant (ou infirmant) cette condition. Lorsqu’une donnée est routée sur une sortie, la données nulle « ? » est automatiquement produite sur l’autre. Le rôle des processeurs de type filtre est de retirer ces données nulles des flots de sorties. Les filtres, comme les aiguillages, définissent leur interface par inférence de type : un aiguillage portant sur un entier produira automatiquement des entiers sur ses deux sorties. x: int
La figure 4 explicite ce comportement, en utilisant un aiguillage et un filtre pour partitionner les valeurs reçues in: int
en entrée. Seules les données inferieures au seuil (ici 50) >50?
in > 50
sont filtrées, ok
ko
• x = [10, 30, 60, 90] • high = [ ?, ?, 60, 90] • low = [10, 30] high: int
low: int
Figure 4 -­‐ Aiguillage & Filtre Exercices (15 points) : Conception de Workflows Scientifique 1. Définition du méta-­‐modèle (5 points) L’intention du méta-­‐modèle que nous souhaitons définir est de capturer le domaine de la conception de worflows scientifiques. Faite le tri dans le descriptif précédent et proposez un tel méta-­‐modèle, en utilisant les concepts du méta-­‐méta-­‐modèle MOF (par ex. avec un diagramme EMF). Montrez l’expressivité de votre méta-­‐modèle en décrivant comment le workflow de la figure 3 peut-­‐être modélisé par votre approche (par ex. dans un tableau associant élément de la figure et méta-­‐classe associée). Indiquez dans un paragraphe quels auraient été les concepts nécessaires à prendre en compte dans un méta-­‐modèle destiné à capturer le domaine de l’exécution des workflows et non leur conception. 2. Contraintes sur le méta-­‐modèle (4 points) Définissez des contraintes OCL sur la base de votre méta-­‐modèle pour assurer les restrictions suivantes : • Un lien entre deux éléments (source, puits, entrée ou sortie de processeur) ne peut connecter que des données de type identique. • Dans un workflow, toute sources (respectivement tout puits) doit être connecté à au moins un processeur. • Un processeur doit avoir au moins 2 entrées pour définir une corrélation. Un croisement ne peut s’effectuer que sur des processeurs prenant exactement 2 entrées. 3. Langage spécifique au domaine (2 points) Définissez par l’exemple un langage domaine (DSL) support à votre méta-­‐modèle (« par l’exemple » = sans donner la BNF, simplement les codes exprimés dans le DSL). Vous proposerez une version textuelle des workflows des figures 3 et 4. Décrivez la mise en œuvre de cette syntaxe dans un outil tel que XText. A quel « coût » chiffreriez vous ce développement ? 4. Profil UML (4 points) Parmi les diagrammes comportementaux d’UML (cas d’utilisation, séquence, activité, état-­‐transition, communication), lequel utiliseriez vous comme support à la mise en place d’un profil de workflow scientifique dans UML ? Proposez le ou les stéréotypes nécessaires au support des processeurs dans les workflows. Illustrez dans un diagramme UML stéréotypé comment vous pourriez mettre en œuvre le workflow de la figure 3. Dans ce cas d’étude, préconiseriez vous l’utilisation d’un DSL ou d’un profil (sur la base de leurs avantages et inconvénients respectifs) ? Argumentation (5 points) Vous postulez sur un poste de commercial dans une société spécialisée en ingénierie des modèles. Lors de l’entretien, le recruteur vous demande de discuter des avantages et inconvénients de la démarche IDM par rapport à un développement plus « classique » des systèmes. Quels arguments mettriez vous en avant dans votre discussion ? Et, à l’opposé, quels peuvent être les freins empêchant la mise en place d’une telle démarche dans un développement logiciel ? Soyez synthétique …