Ingénierie Dirigée par les Modèles pour les SoCs

1. Ingénierie Dirigée par les Modèles pour les SoCs Anne Etien Maître de Conférences INRIA – Projet DaRT Anne.Etien@lifl.fr

2. Note • Ces transparents sont très largement inspirés des cours de Pierre Alain Muller, Jean-Marc Jezequel, Mireille Blay-Fornarino…

3. Plan • Introduction • Modèle, Méta-modèle • Transformation de modèles • UML • Profil • Méthode

4. Raison d’être des modèles • Accroissement exponentiel de la complexité des systèmes informatiques • Besoin de réduire les coûts de développement • Besoin de réduire le temps de mise sur le marché • S’appuyer sur la notion de modèle pour : • Maîtriser la complexité • Réutiliser des parties • Séparer les préoccupations • Fusionner les préoccupations dans le code

5. Attention ! • Les activités d’abstraction/modélisation, séparation/fusion existent depuis toujours • Mais : • les modèles restent parfois implicites • le processus est manuel • De nouveaux noms, de nouveaux standards

6. Qu’est-ce que l’IDM ? • L’IDM correspond à l’utilisation systématique des modèles comme concept clé tout au long du processus d’ingénierie • L’IDM propose une automatisation du processus d’ingénierie, des modèles au code par affinements successifs des modèles

7. Modèle et Méta-modèle

8. Les choses et leurs représentation • Les choses • Réelles, virtuelles • Rares, chères, fragiles, dangereuses, inaccessibles, lointaines, trop nombreuses… • Les concepts pour penser les choses • Plus facile, moins cher, moins dangereux Le tableau de Magritte « Ceci n’est pas une pipe » revisité

9. Qu’est-ce qu’un modèle ? • Définition : « A model represents reality for the given purpose; the model is an abstraction of reality in the sense that it cannot represent all aspects of reality. This allows us to deal with the world in a simplified manner, avoiding the complexity, danger and reversibility » (Jeff Rothenberg) • Un modèle est donc une simplification de la réalité qui permet de mieux comprendre le système à développer • Un modèle ne représente pas toute la réalité mais qu’un point de vue particulier

10. Pourquoi modéliser ? • Un modèle permet de : • Visualiser le système comme il est ou comme il devrait être • Spécifier les structures de données et le comportement du système • Fournir un guide pour la construction du système • Documenter les systèmes et les décisions prises

11. Comment modéliser ? • La manière de modéliser influence fortement • La compréhension du problème • La solution • Il n’existe pas de modèle universel • Multiplicité des niveaux d’abstraction • Multiplicité des points de vue • Le modèle doit être en prise avec le réel

12. Le langage • Les mots pour dire les choses • Outil pour la manifestation externe de la pensée • Plus ou moins généraliste Représentation Méta-modèle Langage pour décrire les choses Représentation Modèle Chose

13. Qu’est-ce qu’un méta-modèle ? • Définition : « A metamodel is a model that defines the language for expressions of a model » (MOF standard version 1.4) • Un méta-modèle permet de définir précisément les concepts manipulés dans les modèles ainsi que les relations entre ces concepts

14. Les niveaux de l’OMG source Méta-Classe Méta-Relation destination Classe Relation Compte numéro : Entier solde : Entier numéro = 108 solde = 1500

15. Transformation de modèles

16. Définition • Une transformation de modèles permet de passer d'un modèle source décrit à un certain niveau d'abstraction à un modèle destination décrit éventuellement à un autre niveau d'abstraction • Ces modèles source et destination sont conformes à leur métamodèle respectif (métamodèles source et destination) et le passage de l'un à l'autre est décrit par des règles de transformation • Ces règles sont exécutées sur les modèles source afin de générer les modèles destination

17. Principe

18. Les règles de transformation • Une règle de transformation définit la manière dont un ensemble de concepts du métamodèle source est transformé en un ensemble de concepts du métamodèle destination. • Il existe les langages impératifs qui décrivent comment la règle est exécutée et les langages déclaratifs qui décrivent ce qui est créé par la règle.

19. Les règles • Trois étapes : • la vérification de la condition correspond à l’analyse du modèle source de la transformation de manière à détecter la présence d’un ensemble de concepts qui correspond à ce que la règle « attend » en entrée. • l’exécution de la règle par le moteur de transformation a lieu pour chaque ensemble de concepts qui valide la condition • et la création consiste à générer un ensemble de concepts dans le modèle de sortie dont les champs sont remplis par les variables affectées durant l’exécution. • L’agencement et la structuration des règles exécutées dans une transformation permet de reconstruire l’ensemble du modèle de sortie.

20. Représentation graphique

21. QVT : le standard de l’OMG • Deux parties déclaratives : Relations et Core • Une partie impérative : Operational

22. Relations • Le langage Relations offre la possibilité de spécier des transformations comme des ensembles de relations entre modèles. Relations équivalent aux règles • Chaque relation contient un ensemble de motifs d'objets. Ces motifs peuvent être reconnus dans les modèles source, créés dans les modèles cible

23. Core • Le langage Core est déclaratif et plus simple que Relations. • L'un des buts de Core est de fournir une base pour la spécification de la sémantique de Relations. • Cette sémantique est donnée comme une transformation Relations vers Core. Cette transformation peut être écrite en Relations.

24. Operational Mappings • Operational Mappings étend Relations avec des constructions impératives et des constructions OCL. • La syntaxe de Operational Mappings fournit les constructions communes des langages impératifs (boucles, instructions conditionnelles, etc.).

25. Boîte noire • Le mécanisme boîte noire permet de brancher et d'exécuter du code externe au cours de l'exécution d'une transformation. Ce mécanisme permet l'implémentation d'algorithmes complexes dans n'importe quel langage et permet de réutiliser des bibliothèques existantes.

26. Moteurs de transformations • Des outils dédiés : • SmartQVT (implémente la partie impérative de QVT) • ATL • Fujaba • Mola • Des outils généralistes : • SiTra • Kermeta • MoMoTE (développé au sein du projet DaRT)

27. Exemple : Gaspard Equational PA Fortran TLM PA

28. UML

29. UML : un langage • UML n’est pas une méthode • UML est un langage de modélisation objet • UML a été adopté par beaucoup (toutes ?) de méthodes objet • UML est dans le domaine public c’est un standard de l’OMG

30. UML un langage pour • Visualiser • Chaque symbole graphique a une sémantique • Spécifier • De manière précise et complète, sans ambiguité • Construire • Aider à la génération automatique (beaucoup d’outils pour la génération SQL des relations à partir de classes) • Développement d’outils pour générer des SoCs à partir d’applications et d’architectures modélisées en UML • Documenter • Les différents diagrammes, notes, contraintes…

31. Les 9 diagrammes UML Diagrammes Cas d’utilisation Classes Etats-transitions Activités Composants Objets Séquences Collaboration Déploiement

32. 5 façons de voir un système

33. Diagramme de composants • Principes : • modélisation du système sous forme de composants réutilisables ; • met en évidence les relations de dépendance entre composants. • Ces diagrammes décrivent l'architecture physique et statique d'une application en terme de modules : fichiers sources, librairies, exécutables, etc. • Les dépendances entre composants permettent notamment d'identifier les contraintes de compilation et de mettre en évidence la réutilisation de composants.

34. Pourquoi le diagramme de composants ? • La réutilisabilité est un facteur important pour la qualité d’un logiciel. • Une classe, de part sa faible granularité et ses connexions figées, ne favorise pas la réutilisabilité. • Pour faire face à ce problème : les composants.

35. La notion de composant • Un composant doit fournir un service bien précis. • Les fonctionnalités qu’il encapsule doivent être cohérentes entre elles et génériques. • Représenté par un classifier structuré, stéréotypé « component », comportant une ou plusieurs interfaces requises ou offertes. • Son comportement interne est masqué. • Pour pouvoir substituer un composant par un autre il suffit de respecter les interfaces requises et offertes.

36. La notion de port • Définition : Point de connexion entre un classifier et son environnement. • Graphiquement, un port est représenté par un carré sur la bordure du classifier. • On peut faire figurer le nom du port à proximité de sa représentation. • Généralement, un port est associé à une interface requise ou offerte.

37. Diagramme de déploiement • Décrit la disposition physique des ressources matérielles qui composent le système. • Montre la répartition des composants sur ces matériels. • Chaque ressource est matérialisée par un noeud. • Précise comment les composants sont répartis sur les noeuds. • Précise les connexions entre les composants ou les nœuds qui existent sous deux formes : spécification et instance.

38. Profil Objectif : spécialiser UML pour un domaine particulier

39. Principes Un profil permet d’adapter UML pour : • Préciser une terminologie propre à un domaine ou à une plateforme • Terminologie EJB : home interfaces, enterprise java beans, archives • Donner une syntaxe à des concepts qui n’en ont pas • Les actions, des nœuds de contrôle dans le domaine du temps réel • Donner une notation différente à des symboles existants • Une image d’ordinateur au lieu d’un nœud ordinaire pour représenter un ordinateur dans un réseau • Ajouter de la sémantique • Gestion des priorités à réception d’un signal, des timers • Ajouter des informations utiles à la transformation de modèles • Règles de transformations vers du code

40. Profil UML • Un profil UML permet de spécifier • la validation • la présentation • Un profil est composé de • stéréotypes • « tagged value » • contraintes

41. Les stéréotypes • Ajout de nouveaux éléments de modélisation qui peuvent être utilisés dans des domaines spécifiques • Les stéréotypes ne peuvent être utilisés que conformément à leur définition • Exemples : • <<interface>>, <<entity beans>>, <<ApplicationComponent>> • Tout concept UML (Classe, Attribut, Association, Use Case, Component, Part…) peut être stéréotypé

42. Les tagged values • Annotation des éléments de modélisation • Définition de propriétés additionnelles à certaines sortes d’élément • Peuvent être définies pour des éléments existants ou des stéréotypes • Virtualisées sous la forme : nom de la propriété, valeur • Exemples • {virtual}, {primary key} • Il est possible d’associer des tagged values à tout concept UML (Classe, Attribut, Association, Use Case, Component, Part…)

43. Les contraintes • Préciser les conditions d’emploi des éléments du modèle • Etendre la sémantique d’UML par l’ajout de nouvelles règles ou la modification de règles existantes • Peuvent être représentées en utilisant soit le langage naturel, soit OCL (Object Constraint Language)

44. Des profils standardisés • SysML, System Modelling Language • MARTE Modeling and Analysis of Real Time and Embedded systems • UML Profile for Schedulability, Performance and Time • UML Profile for System on a Chip • UML profile for Corba • UML Profile for Enterprise Application Integration • UML Profile for Enterprise Distributed Object Computing (EDOC) • …

45. Exemple de profil : Gaspard

46. Exemple de profil : TrML

47. Méthode

48. Qu’est-ce qu’une méthode ? • Définition : « Une méthode est une approche permettant de développer un projet, basée sur une certaine manière de penser, constituée de règles, structurée d’une façon systématique dans les activités de développement correspondant aux produits de développement. » (Brikemper) • Une méthode donne donc les concepts pour décrire le produit et les règles de conduite méthodologiques pour réaliser un produit de qualité avec une efficacité raisonnable.

49. Principe d’une méthode • Deux parties : le produit et le processus (ou démarche) • Le produit est décrit par un ou plusieurs modèles dont les concepts et les relations entre ces concepts sont précisés dans un méta-modèle de produit • Un processus est décrit (quand il est formalisé) sous forme de modèle conformément à un méta-modèle

50. A quoi sert une méthode ? • Modéliser et construire des systèmes de manière fiable et reproductible • Une méthode définit • Des éléments de modélisation • Une représentation graphique • Du savoir-faire et des règles