Une software factory pour le domaine de la simulation dtude

1
Mise en oeuvre desDomain Specific Languages

• Une software factory pour le domaine de la
  simulation détude
• Jean-Marc PRIEUR - ANPROS
• j-m.prieur_at_wanadoo.fr

Version 2.0 2005 DNG/003
2
Sommaire

• Contexte dapplication
• Fabrication dun DSL
• Exemple dexploitation de DSL
• Conclusion
• FAQ

Lopérationnel
La technique
3
Sommaire

• Contexte dapplication
• Des études de recherche opérationnelle aux
  applications de simulation
• Un processus outillé.
• Fabrication dun DSL
• Exemple dexploitation de DSL
• Conclusion
• FAQ

4
Le besoin initial répondre plus efficacement
auxdemandes détudes de recherche opérationnelle
Expert opérationnel, pilote de létude  Je
suis pressé. Jai besoin dune réponse
rapidement. 
5
Rêve du chef
CDT  Je voudrais que les études de RO soient
réalisées plus rapidement en maîtrisant toute la
verticalité
6
Rêve du directeur détude
Directeur détudes  Je comprends son problème.
Il faut maintenant que je le modélise.
- Traduire en termes de critères à évaluer sur
des scénarii, - Construire un plan dexpérience
i.e. développer une application de simulation
dans laquelle je vais mesurer des variables qui
seront transformées en critères
7
La Démarche  Etude RO 
Une réponse Un environnement générique de -
développement,- exécution- et exploitation de
simulations.
Loutil Ductor.NET
8
Rêve du directeur détude qui est le maillon
entre la demande et la réponse
Directeur détudes  Je comprends son problème.
Il faut maintenant que je le modélise. Si la
traduction du modèle en programme informatique
pouvait aller plus vite ...
9
Rêve des développeurs

• Développeur  Je souhaiterais
• - Développer avec des langages et outils
  modernes, efficaces et adaptés au problème.
• Réutiliser ce que jai déjà fait 
• Que les tâches de développement répétitives
  soient faites par lordinateur

10
De quoi avons-nous besoin concrètement?

• Besoin de capitaliser des expertises métiers
• Besoin dusines de développements dapplications
  de simulation
• Assembler des applications de simulation avec des
  outils, en sexprimant dans un langage proche de
  lopérationnel, et sappuyant sur des briques de
  connaissances métier (moyens concepts demploi)
• Cette usine de développement doit être intégrée à
  un environnement de développement moderne
• Besoin dun langage pour le binôme opérationnel /
  ingénieur pour les applications
• La situation passée notation UML

11

• Lenvironnement de développement, exécution, et
  exploitation de simulations
• Ductor.NET

12
Contexte dapplication
13
Créer des applications de simulation

• A lANPROS, nous créons des applications de
  simulation pour les études de recherche
  opérationnelle
• Processus de développement basé sur une analyse
  de haut niveau en privilégiant UML notation
   general purpose  (depuis 1999)
• Mais
• Cest une affaire de spécialiste génie logiciel
• Or ceux qui ont besoin des simulations détude
  peuvent être des opérationnels (qui ne
  peuvent/veulent pas forcément parler UML) et ne
  peuvent / veulent pas aller trop loin dans le
  code. Or il faut pouvoir collaborer.
• Et
• Nos applications de simulation sont basées sur un
   framework de simulation  générique et complexe
  qui capture et factorise ce qui est commun aux
  applications de simulation détude.
• Les modèles représentent visuellement les
  variations (points dinsertion) que permettent le
  framework
• Or le modeleur UML ne connaît pas ce framework,
  et ce nest pas forcément facile de le lui
  apprendre.

14
Créer, maintenir des applications de simulation à
partir de modèles

• Nous avons identifié 4 types de modèles
• pour spécifier, concevoir et développer des
  applications de simulation
• Parmi ceux-ci, la notion de  Comportement .
• Ex le comportement du chien ou de lhélicoptère
  de la vidéo.
• Il est complexe en soi.

• Mais les choses sont encore plus compliquées par
  le manque dinteraction entre le modèle et le
  framework de simulation sous-jacent ou les
  composants de simulation réutilisés qui
  contraignent la modélisation

IntelliSense au niveau du modèle, débugging idem .
15
Développement dapplications de simulation par
les modèles

• Nous cherchons à rendre la modélisation
  dapplications de simulation possible par des non
  spécialistes (un plus grand nombre)
• Sattacher aux concepts
• Masquer le plus possible les détails du framework
  et aider à lapprendre
• Avoir des éditeurs graphiques attractifs et
  ergonomiques qui parlent dans le langage de
  lopérationnel.

• Les DSL une solution possible
• Assembling Applications with Patterns, Models,
  Frameworks and Tools
• Microsoft nous fournit des outils  les DSL
  Tools pour créer des éditeurs graphiques
  permettant de manipuler nos modèles spécifiques
  / métier

16
Ductor.NET pourquoi ça va plus vite !
Ce qui est commun aux applications de simulation
est factorisé dans des framework

• Des framework génériques
• Génie logiciel, métiers techniques.
• Framework de simulation
• Des modèles dexpertise métier  Marine 
• Capitalisés au fur et à mesure des études
• Un environnement de développement dapplications
  de simulation
• Dans Visual Studio.NET 2005 (Beta2)
• La modélisation y tient une place importante
• Un environnement dexploitation
• (pas encore réalisé)

Ce qui est spécifique à une application de
simulation est capturé dans des modèles
17
Sommaire

• Contexte dapplication
• Fabrication dun DSL
• Exemple dexploitation de DSL
• Conclusion
• FAQ

18
De quoi parlons nous

• DSL Package de langage VS 2005
• Nécessite le VS 2005 SDK (VSIP)

Editeurs, toolboxs, etc
19
Utiliser les DSL Tools

• Cest fabriquer un Package de Visual Studio.NET
  2005 qui
• Sait manipuler un modèle conforme à un méta
  modèle que vous définissez par la Domain Model
  Definition
• Via un éditeur graphique dont vous décidez la
  notation graphique (Designer Definition)
• Sait créer à partir de ce modèle les artefacts
  que vous voulez (fichiers sources, fichiers de
  configuration, etc ) par vos générateurs de code
• En particulier génération de code ciblant vos
  frameworks
• Sait faire persister ce modèle

Conforme
méta modèle
Microsoft DSL Tools
Générateurs Code
Éditeur graphique
Designer Definition
Génère
VS.Net 2005
Framework
20
Utiliser les DSL Tools

• Cest fabriquer un package de Visual Studio.NET
  2005 qui
• Sait manipuler un modèle conforme à un méta
  modèle que vous définissez par la Domain Model
  Definition
• Via un éditeur graphique dont vous décidez la
  notation graphique (Designer Definition)
• Sait créer à partir de ce modèle les artefacts
  que vous voulez (fichiers sources, fichiers de
  configuration, etc ) par vos générateurs de code
• En particulier génération de code ciblant vos
  frameworks
• Sait faire persister ce modèle
• Ce package est fabriqué dans Visual Studio .NET
  2005
• à laide des DSL Tools (actuellement en Community
  Technology Preview)
• Il est basé sur les assemblages du VSIK (Visual
  Studio SDK) et les assemblages VisualStudio.Modeli
  ng.Sdk livrés avec les DSLTools.

21
Le processus de création dun DSL avec les
DSLTools
Assistant Crée et configure une solution Visual
Studio.NET pour un éditeur de DSL (à partir dun
patron)
Définition du DSL
Création dun installeur pour le déploiement du
DSL
Partie  Package VS.NET 
Édition du  Domain Model  Méta modèle
(DMD) Sérialisation du modèle Contraintes
Génération de code de léditeur graphique
Ajout de code Corps des contraintes Import /
Export personnalisé Autres enrichissements
Édition de la définition de léditeur
graphique Notation graphique(DD) Lien entre méta
modèle et Notation graphique Explorateur Fenêtre
des propriétés Comportement de validation Sérialis
ation de létat de léditeur
Build (F5)
Exécution Lancement dune instance expérimentale
de VS.NET sur la solution de debugging
Test Debugging Utilisation du designer Génération
dartefacts Modification de patrons
22
Microsoft DSL Tools pour résumer
Conforme
métamodèle
Microsoft DSL Tools
Générateurs Code
Éditeur graphique
Génère
VS.Net 2005

Framework
23
Fabriquons un DSL pour les comportements
Introduction à démo
24
Un exemple de modèle Le comportement du chien /
hélicoptère (UML)
Playing
AfterPartDeactivate(part, stopping, endStatus)
ltltSubBehavior(reach)gtgt
ltltSubPart(catcher RectilinearMover)gtgt
Going Away
Catching
entry/ reach.LocatableToReach targetLocation
entry/ catcher.Initialize(pos,
(target.Position-pos).Normalize
d(speed),
target)
FetchIt( target )
ltltSubBehavior(reach)gtgt
ltltSubPart(reacher IsotropicGuidedReacher)gtgt
Coming Back
Reaching
entry/ reach.LocatableToReach commanderPlayer
entry/ vel (target.Position-pos).Normalized(spee
d) reacher.Initialize(pos, vel,
target)
AfterPartDeactivate(part, stopping, endStatus)
NotifyParentReached(this)
ltltSubPart(reacher IsotropicGuidedReacher)gtgt
ltltSubBehavior(reach)gtgt
Following
Following
entry/ reach.LocatableToReach commanderPlayer
Wander
GoBack()
GoBack()
Sit Down
Staying
Sit Down
Wander
ltltSubPart(mover ErraticMover)gtgt
Wandering
entry/ if (vel.IsZero) vel pos.LocalBase0spe
ed mover.Initialize(pos, vel,
this.period)
25
Fil rouge un automate de comportement

• Considérons un petit automate de comportement
• Il y a des notions spécifiques à la simulation
  (détude)
• Par exemple les transitions temporelles
  (after(dt) sont en temps simulé)
• Des transitions automatiques correspondent à des
  événements de terminaison du Framework de
  simulation
• Certains types détats correspondent à la
  délégation à un composant de simulation (Sous
  composants quil faut démarrer, attacher à leur
  parent, initialiser puis stopper en fin détat)

Playing
AfterPartDeactivate(part, stopping, endStatus)
ltltSubBehavior(reach)gtgt
ltltSubPart(catcher RectilinearMover)gtgt

Going Away
Catching
entry/ reach.LocatableToReach targetLocation
entry/ catcher.Initialize(pos,
(target.Position-pos).Normalize
d(speed),
target)
FetchIt( target )
ltltSubBehavior(reach)gtgt
ltltSubPart(reacher IsotropicGuidedReacher)gtgt
Coming Back
Reaching
entry/ reach.LocatableToReach commanderPlayer
entry/ vel (target.Position-pos).Normalized(spee
d) reacher.Initialize(pos, vel,
target)
AfterPartDeactivate(part, stopping, endStatus)
NotifyParentReached(this)
ltltSubPart(reacher IsotropicGuidedReacher)gtgt
ltltSubBehavior(reach)gtgt
Following
Following
entry/ reach.LocatableToReach commanderPlayer
26
Création dun DSL
27
Pour notre exemple, que nous manipulons (par
VS.NET 2005)

• Plusieurs niveaux

28
Utilisation des modèles les générateurs de code

• Le Designer est accompagné de générateurs de
  code, doc, fichiers de config, etc

29
Générateur de code par template T4
lt_at_ generatedFile extension".cs" gt lt_at_
modelFile path"Empty.sm" gt lt foreach (
StateMachine sm in context.StateMachines ) gt
public class ltsm.Namegt public enum State
lt foreach ( State state in sm.States
) gt ltstate.Namegt, lt
gt
30
Générateur de code plus sophistiqué (en C)
lt_at_ generatedFile extension".cs" gt lt_at_
modelFile path"Empty.sm" gt ltcontext.Codegt
public partial class Playing /// ltsummarygt
/// Enumeration representing the states of the
object /// lt/summarygt enum State
Catching, Reaching, Following ///
ltsummarygt /// current state of the object ///
lt/summarygt private State state /// ltsummarygt
/// AfterPartDeactivate EventHandler ///
lt/summarygt public void AfterPartDeactivate()
switch(state) case State.Catching
state State.Reaching break case
State.Reaching state State.Following
break
public static string Generate(LanguageStateMachine
sContext context) System.Text.StringBuilder
sb new StringBuilder() int i 0
sb.AppendLine("public partial class "
context.InputPath) sb.AppendLine("")
sb.AppendLine(" /// ltsummarygt")
sb.AppendLine(" /// Enumeration representing the
states") sb.AppendLine(" /// lt/summarygt")
sb.AppendLine(" enum State") sb.AppendLine("
") foreach (State s in context.States)
sb.Append(" " s.Name) if (i
context.States.Count - 1) sb.AppendLine()
else sb.AppendLine(",") i
31
Génération de code encore plus intégré
32
Sommaire

• Contexte dapplication
• Fabrication dun DSL
• Exemple dexploitation de DSL
• Conclusion
• Questions / Réponses
• MDE UML / MDA / DSL

33
LEnvironnement de développement Simulations
Introduction à démo
34
Vie dune application de simulation
? Modèle danalyse dune application de simulation
Bibliothèque de modèles capitalisés
? Conception de nouveaux composants de
simulation
? Mise au point
Structure dynamique
? Exécution
Structure statique
Code utilisation expertise
35
Le sujet

• Travail dune frégate et de son hélicoptère
• La frégate suit un chemin et lance lhélicoptère
  de temps en temps.
• Lhélicoptère va directement en un point désigné,
  fait ce quil a à faire (détection ) , et
  revient à la frégate (guidage)

Station
Rejoint le porteur par un mouvement guidé
Rejoint le point de station par un mouvement
rectiligne
36
LEnvironnement de développement Simulations
37
Ce que nous avons vu dans la démo

• Des designers qui présentent des concepts
  spécialisés dans des modèles spécifiques
• Des générateurs de code qui savent prendre ces
  modèles et générer du code ciblant un framework.
• Une excellente intégration à VS 2005
• Une autre façon darchitecturerses projets

38
Un découpage des classes par domaine

• Grâce aux classes partielles

Domaine
Classes
Main.cs
Application.simu
Frigate.Behavior.sm
Helicoptere.cs
Station.simu
Station.Behavior.sm
39
Sommaire

• Contexte dapplication
• Fabrication dun DSL
• Exemple de DSL dexploitation
• Conclusion
• FAQ

40
Les concepts manipulés par les DSL Tools

• Les DSL Tools utilisent le même framework de
  méta-modélisation que les autres designers de VS
  2005
• Les DSL Tools sont fabriqués avec les DSL Tools
• Mais il y a encore du code spécifique qui nest
  pas généré
• Le bootstraping est un objectif
• Il y a un méta modèle pour
• Le DMD (Microsoft Metadata Framework)
• Le DD (en fait un schéma XML)

41
La DMD
On y trouve des SimpleType et des énumérations
composées dEnumerationLiteral
On y trouve des SimpleType et des énumérations
composées dEnumerationLiteral
Un Model peut étendre dautres modèles
Des Concepts (supportant héritage, et notion
d abstract ) sont reliés par des Relationships
Les Roles des relationship permettent de naviguer
de concept en concept
Concepts et Relationships peuvent avoir des
propriétés.
On peut également préciser dautres infos
(browser, implémentation)
42
Calendrier des DSLTools

• Les Community Technology Preview
• 6 octobre 2004 1ère version (éditeur de domain
  models dans VS 2005 B1 un tutorial)
• 28 décembre 2004 2ème version (éditeur
  assistant diagrammes Add-in générateur T3)
  suivi le 15 janvier 2005 3 tutoriaux (pour
  lutiliser)
• 15 Mars 2005 Amélioration des warnings /
  erreurs concernant le .DD
• 29 mai 2005 pour VS 2005 B2, formes à
  compartiments, T4 plus rapides, compatibilité
  avec les autres designers.
• 19 septembre 2005 nouveaux modèles de base,
  nombreuses corrections de bugs.
• Q1 2006 ? V1 des DSL-Tools
• Avec Orcas V2 ?

43
Retour dexpérience sur la mise en application

• Un travail déclaireur
• Saider du forum de discussion
• Léquipe des DSLTools (initialement 4 personnes)
  y est très disponible.
• Des outils prometteurs
• Voir le résultat possible à terme (les designers
  de VS.NET 2005)
• Les DSL Tools sont encore un peu complexes à
  manipuler
• Saider de DSL DM -gt DD pour synchroniser le .dd
  avec le .dmd
• Installer T3Colorizer pour scripter les T4
• lintégration modélisation / code est déjà très
  appréciée par utilisateur final
• Vivement la version v1
• Notamment pour la documentation
• Il nous reste un certain travail avant
  datteindre notre objectif dEDS
• Mais cest en bonne voie la faisabilité est
  démontrée aujourdhui. Les retours utilisateurs
  sont très positifs, même si nous continuons à
  faire évoluer les designers.

44
Pour en savoir plus

• Sites Web
• http//lab.msdn.microsoft.com/teamsystem/workshop/
  DSLTools
• Download des DSLTools (septembre 2005 pour le
  moment), et lien pour télécharger le VSIP Beta 2.
• 4 Tutoriaux (Walkthroughs)
• Liens vers les blogs de léquipe DSL
• Liens vers le forum de discussion
• http//www.modelisoft.com/dmd2dd.aspx
• DSL DM -gt DD helper tool permettant de réaliser
  le mapping entre le domain model (.dsldm) et la
  designer definition (.dsldd)
• T4Colorizer apporte la coloration syntaxique
  aux Templates T4.
• Communauté DSLTools
• http//forums.microsoft.com/msdn/ShowForum.aspx?Fo
  rumID61
• La communauté DSL Tools est très active.
• A propos de Ductor.NET
• http//escadre.cad.etca.fr/contrib/monod

45
FAQ

• Combien couteront les DSLTools ?
• Ils seront gratuits, normalement dans le VS SDK.
• Est-ce quon est obligé dhéberger nos DSL dans
  VS 2005 ?
• Oui, pour le moment (sauf version Express)
• A terme, on pourra se procurer un VS  vide 
• Puis, on pourra héberger les designers hors de VS
  (V2 des DSLTools)
• Est-ce quon ne pourrait pas faire la même chose
  en UML ?
• Cétait ce que nous faisions avant, mais
• on a des compartiments spécifiques du métier
  pour le DSL  Simulation Architecture  et le DSL
   State Machine  comporte la notion de
   Délégation à une entité de simulation 
• Les deux connaissent le Framework et
  interagissent avec les assemblages de modèles.
• Tout est intégré et synchronisé dans le processus
  de production de code.

46
Mise en oeuvre desDomain Specific Languages

• Annexe-A
• Création dun DSL

Version 2.0 2005 DNG/003
47
Créer notre DSL dans VS.NET Projet  Domain
Specific Langage 

• Création dun DSL et dun éditeur graphique

48
On obtient une solutions VS.NET avec 4 projets
Un éditeur graphique de méta-modèles, sa toolbox
et ses toolbars.

• 3 projets pour
• Le méta-modèle
• léditeur graphique
• La plomberie (package VSIP)
• un projet de debugging

49
Description du DSL

• La Domain Model Definition
• Décrit le méta modèle
• Ici Concept  State  et relation  Transition 
  ayant des rôles (cardinalité)
• Permet de générer un assemblage .NET
  (ObjectModel) qui sait
• Contenir le méta modèle
• Lire / Ecrire (XML)
• Il existe un éditeur graphique pour manipuler le
  DMD
• La Designer Definition
• Décrit la syntaxe graphique qui sera utilisée
• Décrit la boite à outils, les explorateurs,
• Décrit le lien entre les concepts / relations et
  la syntaxe graphique
• Pas déditeur graphique pour le DD (cest du
  XML!)
• Donne lieu à un assemblage .NET le Designer

ltshapesgt ltgeometryShape name"BShape"
initialWidth"2.0" initialHeight"0.75"
geometry"Rectangle"gt ltdecoratorsgt
ltshapeText name"Name" position"Center"
defaultTextId"BShapeNameDecorator"/gt
lt/decoratorsgt ltfillColor color"blue"
variability"User"/gt ltoutlineColor
color"black" variability"User"/gt
lt/geometryShapegt lt/shapesgt
50
Mise en oeuvre desDomain Specific Languages

• Annexe-B
• Création dune application de simulation

Version 2.0 2005 DNG/003
51
Le sujet

• Travail dune frégate et de son hélicoptère
• La frégate suit un chemin et lance lhélicoptère
  de temps en temps.
• Lhélicoptère va directement en un point désigné,
  fait ce quil a à faire (détection ) , et
  revient à la frégate (guidage)

Station
Rejoint le porteur par un mouvement guidé
Rejoint le point de station par un mouvement
rectiligne
52
Le modèle statique du comportement  Station 
53
Le modèle dynamique du comportement  station 
54
Ajout dun  main 

• Les fichiers
• Ce qui concerne la pièce comportementale
   Station 
• Le reste de lapplication

55
Un peu de code à ajouter (métier)

• Implémentation de linterface IMoveable en
  fonction de létat.

56
Un peu de code à ajouter (métier)

• Un événement .NET (pas encore géré par le DSL)
• Des constructeurs des sous-parts (choix de le
  différer), peut être copié/collé de code généré
  sans loption delayCreation.

57
Application de test
58
Le comportement de la frégate
/
59
Visual Studio SDK Concepts clés

• Ruche expérimentale
• Le SDK crée une ruche séparée de registry pour le
  travail de prototypage
• Les exemples sauto-inscrivent dans la ruche
  expérimentale
• Il est possible den faire un reset all
• DLK and PLK
• Les développeurs utilisent la Developer License
  Key, fournie avec le SDK
• Le déploiement requiert une Package Load Key
• Ostensible en http//www.vsipdev.com/plkregister.a
  spx