Skip to end of metadata
Go to start of metadata

TPs Lignes de Produits et Variabilité

Séance 1 : introduction à la variabilité et à FAMILIAR

Cette séance est décomposée en 3 étapes :

  1. Retour sur la variabilité : rappel de cours
  2. Syntaxe de Familiar :
  3. Simulateur de créature et Variabilité
    • Réfléchir à la variabilité présente dans la version du simulateur livrée pour le TP long
    • Ecrire petit à petit un feature model la capturant
    • Essayer de distinguer la variabilité du domaine (indépendante des détails d'implémentation) de la variabilité technique

Pour information, la page d'installation de FAMILIAR est : https://github.com/FAMILIAR-project/familiar-documentation/tree/master/installation

La page du manuel en ligne est: https://github.com/FAMILIAR-project/familiar-documentation/tree/master/manual

Lancement de la version interactive :

java -jar -Xmx1024M FML-environment-1.1.jar 

Séance 2 : Modélisation séparée et correspondance modèles de variabilité/asset

Modélisation de la variabilité

  • Séparez explicitement la variabilité de votre simulateur entre domaine (utilisateur/configurateur) et technique (développeur, mainteneur de la ligne de produits) avec deux feature models
  • Analysez les liens qu'il faudrait faire entre ces deux FM à l'aide d'implications ou d'équivalences entre features.

La commande suivante permet de créer un FM unique contenant deux FM en définissant des liens entre les deux :

regles = constraints( A -> B; )
fmSimu = aggregate { fmA fmB } withMapping regles
  • Réalisez le script d’agrégation des FM avec des contraintes entre eux.

Utilisation de Familiar à travers son API Java

  • Téléchargez l'archive suivante : simu-generator.zip  attention, nouvelle version du 30 novembre à 13h25 sans vérification de la configuration terminée par "isComplete" : il y a actuellement un bug de régression dans la fonction "isComplete" qui détermine si une configuration est complète (toutes les features qui doivent être sélectionnées au minimum le sont). Il ne vous est pas demandé de déterminer la complétude d'une configuration, juste une configuration valide.

Ce projet montre l'utilisation de Familiar à travers une API programmatique en Java. Il utilise Maven pour récupérer automatiquement les dépendances nécessaires. Lancez la commande "mvn clean install" pour téléchargez automatiquement les dépendances manquantes.

  • Expérimentez la petite application fournie ("mvn -P run")
  • Modifiez le projet pour utiliser le script que vous avez défini pendant la première partie du TP
  • Imaginez et implémentez un programme de réalisation qui prend une configuration (du domaine, et peut être partiellement du FM technique) en paramètre et va réaliser un produit final.

Ecrivez ce programme de manière incrémentale en essayant de respecter les principes de génie logiciel (décomposition d'une architecture) au fur et à mesure de vos incréments.

Tous les produits définis dans le FM sont-ils réalisables ?

N'hésitez pas à modifier les FM en fonction de vos besoins.

Séance 3 : TP long à rendre

Résultat attendu

  • Modélisation d'un feature model de domaine. Pensez à la vitesse de simulation spécifiée de manière non technique, peut être la forme des créatures
  • Modélisation d'un feature model de l'implémentation. Celui-ci doit être directement lié à votre architecture (celle du TP 5, sans forcément de chargement dynamique, mais avec peut être quelques ajouts pour avoir plus de variabilité, différentes formes de créatures, affichage graphique optionnelle ou configurable, etc.)
  • Liaison entre les deux features models pour qu'une configuration du FM de domaine agissent sur le FM d'implémentation.
  • Connexion du code du simulateur (version du TP long à rendre sans forcément le chargement des plugins) avec l'API Familiar en Java pour lire les scripts de configuration Familiar correspondants aux FMs de domaine et d'implémentation reliés par les contraintes
  • Démonstration d'au moins une configuration automatique de bout en bout (chargement par le simulateur des FMs, configuration par script du FM de domaine, qui impacte le FM d'implémentation, lecture par le code du simulateur de la configuration résultante du FM d'implémentation et configuration du code correspondante)
  • Prise en compte de plusieurs implémentations de variabilité dans le code du simulateur (l'injection de valeur de paramètres et la gestion des patterns Strategie est un minimum attendu, d'autres sont possibles)
  • Mise en place d'une architecture de configuration pour faciliter la connexion entre configuration du FM et implémentation(s) des types de variabilité. Il est attendu que la conception de cette architecture soit décrite dans le README et utilise éventuellement les différents mécanismes vus en cours (héritage, généricité, patrons...).

Modalités

  • Travail par équipe de 3 ou 4 (une équipe de 4 doit rendre un travail de meilleure qualité), par défaut les groupes sont identiques à celles du TP long précédent
  • Changement de groupe possible par mail avant le lundi 7/12/2015 23h59 (heure de Paris) (Philippe POINT Collet AT unice POINT fr)
  • Envoi par mail d'une archive (zip) à Philippe Collet (Philippe POINT Collet AT unice POINT fr), date limite d'envoi : dimanche 13/12/2015 mercredi 16/12/2015 à 23h59 (heure de Paris)
  • Contenu de l'archive :
    • pom.xml (maven)
    • fichiers source (répertoire src)
    • fichiers test (répertoire test)
    • feature models et éventuels scripts associés
    • fichier README.pdf contenant des explications (choix de conception des feature models, assets utilisés, méthodes de réalisation de la variaiblité implémentées)

Barème

  • Justification et documentation des choix de conception, README : 2 points
  • FM de domaine : 2 points
  • Sous-partie du FM de domaine sur des démos préconfigurées : 1 point
  • FM d'implémentation : 2 points
  • Liaison entre les FM : 2 points
  • Configuration de bout en bout de l'architecture : 2 points
  • Démos fournies (pom.xml) de bout en bout : 1 point
  • Nombre d'implémentation de variabilité différentes : 4 points
  • Qualité de l'architecture de configuration implémentée : 4 points

Liste des équipes

  1. Remy Garcia, Djoe Denne, Thomas Grillo (3) ok
  2. Remi GIANGRASSO, dominique DIB, diana RESMERITA, kévin CAUCHETEUR (4) ok
  3. Thibaud Canale (1) ?
  4. Mathias Ellapin, Charles Heitzler (2) ok
  5. FINKELSTEIN Arthur, AUDIBERT Julien, EL HAJAMI Mehdi, LIMAM Mohamed (4) ok
  6. Belhassen Issam, Fezai Ahmed, Chebaane Meriem (3) ok
  7. Adrien Mannocci, Sofiane Naït Ouslimane, Johann Allena, Jean-Baptiste Dravet (4) ok
  8. Daniel Arasu ANBARASU, Youssef yassine, aymen Baya, naima (4) ok
  9. BARRY Dieila, BWATA ESALU Costel, BELHI Achraf (3) ok
  10. Alison BERLIOZ, Hamza BOUDRADAR, Maxime DRAY, Vaki RIVET (4) ok
  11. SEREE Yann, FAGARD Christophe, LAVOISIER Clément (3) ok
  12. Guillaume FAGUET (1) ?

 

  • No labels