13.07.2015 Views

Outils pour l'IDM

Outils pour l'IDM

Outils pour l'IDM

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

<strong>Outils</strong><strong>pour</strong>l’IDM8 février2010YohannLECOMMANDOUX


SommaireSemaine 1...................................................................................................................................... 3Introduction .............................................................................................................................. 3La notion d’architecture logicielle ............................................................................................. 4Semaine 2...................................................................................................................................... 8Introduction .............................................................................................................................. 8Au niveau des langages ............................................................................................................ 8Du metamodèle au langage. ..................................................................................................... 9Comment résoudre ce problème ? ........................................................................................... 9Conclusions ............................................................................................................................. 10Semaine 3.................................................................................................................................... 11Présentation d’UML (Unified Modeling Language) ................................................................. 11SysML ...................................................................................................................................... 11Semaine 4.................................................................................................................................... 13Introduction ............................................................................................................................ 13Les différentes approches ....................................................................................................... 13Exprimer la variabilité ............................................................................................................. 14Semaine 5.................................................................................................................................... 15Introduction ............................................................................................................................ 15L’ingénierie système ................................................................................................................ 15Ingénierie des exigences ......................................................................................................... 15Architecture de développement ............................................................................................. 16Mise en place de cette structure ............................................................................................ 16Description de la solution ....................................................................................................... 17Développement de la solution ................................................................................................ 17Semaine 6.................................................................................................................................... 19Introduction ............................................................................................................................ 19Modèle à l’exécution ............................................................................................................... 192


Semaine 1IntroductionQu’est-ce qu’un système ?Un système est un ensemble d'éléments en interaction, aussi bien entre eux qu' avecl'environnement. Son but est de rendre des services correspondants à sa finalité. Dans cette phrase,on remarque l’expression : ensemble d'éléments en interaction. On peut en déduire qu'à l’intérieurd’un système différents éléments interagissent, ces éléments peuvent être de deux types : matérielou logiciel.Quel est le rapport avec les modèles ?Les modèles permettent de refléter un ou plusieurs aspects d’un système ou une partie de cedernier. Ainsi, le modèle abstrait le système afin de rendre possible une réflexion sur celui-ci. On<strong>pour</strong>ra donc mieux communiquer, analyser et spécifier le modèle entre initiés. Pour cela, il estnécessaire d’utiliser un langage spécifique au système : c'est-à-dire un DSL (Domain SpecificLangage).Es-ce que l’ingénierie dirigée par les modèles est une idée récente ?On peut se demander si l’idée d’utiliser des modèles est réellement efficace, et si tel est le cas,<strong>pour</strong>quoi n’y a-t-on pas pensé avant. Il se trouve que cette idée est loin d'être récente. En effet, lesmodèles ont déjà prouvé leur utilité, en mécanique par exemple. Léonard de Vinci, lui-même, lesutilisait déjà (voir Figure 1). Plus récemment, les modèles sont utilisés en permanence enélectronique. La notion de modèle a ainsi prouvé son efficacité dans de nombreux et permet auxpersonnes comprenant un même modèle de communiquer.Figure : Modèle de parachute3


En réalité, ces notions d’architecture sont tellement larges, qu’elles peuvent être étendues àd’autres domaines. Afin de supporter cette description, des centaines de langages ont émergés. Onpeut les classer en deux grandes familles :• Architecture description language (ADL)• Component based software engineeringLes ADL sont orientés développement top down c'est-à-dire à partir d’une structure gros grain,alors que les components based software engineering sont orientés bottom up.Il existe de nombreux langages. Pour n’en citer que quelques-uns metahH, AADL, CLARA, PECOS,COTRE, Rapide, Wright, Think, Rubus, Koala, VEST, PACC, PBO, giotto, EAST-ADL2, .Net, OSGI,Modelica, altarica, Simulink, scicos, BIP…Tous ces langages sont des DSL. Ils sont utilisés par les spécialistes du domaine, et sont simplesd'utilisation <strong>pour</strong> eux. Ils requièrent tous un outillage dédié qui ne sont pas interopérables entre eux.Cependant, ils sont tous destinés à un but précis tels que l’exécution, le déploiement, la spécification,l’analyse, etc.…FonctionnementCes différents langages partagent de nombreux de points communs. Ils possèdent descomposants, des interfaces, des connecteurs, le tout reliant les composants dans le but de réaliserune architecture.Ces composants peuvent être de plusieurs types :• Code binaire• Code source• Langages formels• Mathématique• ConfigurationCes différents types de descriptions n'étant pas exclusifs, on peut donc en cumuler plusieurs.Pour accéder à l’intérieur d’un composant, on utilise des interfaces qui peuvent être dedifférentes natures :• Fournies/Requises• Entrées / sorties• Bidirectionnelles• Non orientéesDe même, elles peuvent avoir différents rôles :• Fonctionnel• Configuration• SynchronisationUn composant possède également plusieurs niveaux de visibilité. Tout d’abord la visibilité boîtenoire qui est limitée si l’on veut donner une représentation un peu abstraite de ce qui se passe dansce composant. Elle peut autrement être boîte blanche, dans ce cas tout est visible depuis l’extérieur.Enfin, il existe un mode intermédiaire qui est le mode boîte grise.Pour relier les composants, plusieurs stratégies sont possibles :5


• soit les composants sont homogènes avec le même type d’interface, dans ce cas on utilise lesliens logiques.• soit ils sont hétérogènes, on a donc des comportements prédéfinis ou des comportementsdécrits par une configuration.Certaines contraintes peuvent être appliquées au système. C’est ce que l’on appelle un stylearchitectural. Grâce aux contraintes, il attribue des propriétés au système. Il peut être appliqué soustrois formes :• Ensemble de contraintes sur les composants• Ensemble de contraintes sur les associations entre ces composants• Permet d’obliger une organisation particulière des composantsLes styles architecturaux sont classiquement :• Pipe and filter• Blackboard• Object oriented• Layered systemLes types de description architecturale :• Logiqueo Le logiciel développé Structure gros grain de l’interaction des composants• Description et mise en œuvre des algorithmes• Techniqueo Plate forme de déploiement Service offert par l’OS/ l’intergiciel• Descriptions du matériel• Opérationnelleo Allocation de l’architecture logique sur l’architecture techniqueProblèmes• Multiplication des langages• Difficultés d’interaction• Difficultés de compréhension de la sémantique• Difficultés d’installation des logiciels associés• Difficultés de prise en main des outilsAvantages• Permet de maîtriser la complexité (abstraction puis raffinement)• Facilité de réutilisation (encapsulation au travers de composants)• Cadre permettant la prise en compte des principes de génie logiciel (styles architecturaux)• Base de raisonnement à des fins d’analyses et de validations6


• DocumentationEt les modèles ?«De manière plus générale, l’ingénierie dirigée par les modèles offre un cadre méthodologique ettechnologique qui permet d’unifier différentes façons de faire dans un processus homogène. Il est ainsipossible d’utiliser la technologie la mieux adaptée à chacune des étapes du développement, tout enayant un processus global de développement qui est unifié dans un paradigme unique »(Jezequel,Gérard, Baudry)La technique à utiliser est d’unifier les langages de la manière suivante :1) Au travers d’un langage commun2) En facilitant le passage d’un langage vers un autre3) Unifier l’utilisation des différents outils4) En fournissant les concepts communs aux différents ADL5) En fournissant un pivotEt la sémantique comportementale ?L’aspect concernant la sémantique comportementale est rarement traité.Exemple d’application :On constate en entreprise que durant les phases de développement, l’utilisation d’un cahier descharges contenant des diagrammes UML est devenu indispensable. L’efficacité des modèles dans ledomaine de l’informatique n’est plus à démontrer. De même, dans le domaine de l’électronique,l’usage de modèles <strong>pour</strong> représenter des schémas techniques est une notion depuis longtempsexploitée.7


Semaine 2IntroductionPartons du principe que nous avons un métier : éplucher des pommes. Si l’on souhaite éplucherune pomme, un couteau suisse suffit. Mais quand on a des tonnes de pommes, le couteau suisse nesuffit plus, on commence donc à fabriquer des outils adaptés <strong>pour</strong> aller plus vite. On spécialise notreoutil de base. Dans notre cas du couteau suisse, on passera à l’économe. Mais attention, si on sespécialise de trop (mise en place d’un éplucheur de pommes), alors on ne <strong>pour</strong>ra plus s’élargir àd’autres domaines (les poires par exemple). Afin de bien comprendre ce raisonnement, nous sommespartis d’un langage DSL : ADORE. Basé sur du prolog , il permet de générer du SOA et de raisonnersur des modèles. Un petit langage a été ajouté permettant en 400 lignes, de réaliser l’équivalent de5000 lignes de Prolog . Le passage d’un langage à l’autre se fait par compilation.Au niveau des langagesL'utilisation des langages est omniprésente, car se sont des moyens d’échange, decommunication, de design et d’implémentation des systèmes. On va ainsi donner de nouveauxniveaux d’abstraction <strong>pour</strong> encapsuler la complexité.Dans un langage, on a un code source. Ce code source est un mot d’une grammaire, qui est unmot de la grammaire des grammaires (eBNF).Au niveau du code source, il s’agit de la syntaxe concrète. A l'extrémité se trouve la syntaxeabstraite qui constitue ce que l’on a voulu dire. Pour passer de la syntaxe concrète à la syntaxeabstraite, on passe par deux phases : un analyseur lexical qui produit des lexèmes que l’on utilise dansun analyseur syntaxique.8


Certains langages tel que le Scheme ne possède pas de différence entre leur syntaxe concrète etleur syntaxe abstraite.Rappel sur le rôle du compilateurUn compilateur part d’un langage source et produit à partir de ce langage, un langage cible.Du metamodèle au langage.On a une chose, un objet, qui constitue notre système. Ce système est représenté par un modèlequi est conforme à un métamodèle représentant un langage. Si ce modèle est conforme aumétamodèle, alors il doit être un mot du langage : c'est ce que l'on appelle un métatriangle. Cetriangle est vrai tout le temps et à tous les niveaux.LangageReprésenteEst un mot deMétamodèleEst conformeModèleL’idéal serait qu’un modèle puisse se transformer en texte et vice versa. On prend donc ungénérateur de textes qui utilise des templates. Ces derniers, à partir du modèle, génèrent du texte.Pour l’opération inverse, il faut écrire un analyseur syntaxique et lexical qui utilise une grammaire.Celui-ci produit alors un AST utilisé par un interpréteur, qui produit ainsi un modèle. L’inconvénientde cette démarche est que si l’on effectue une modification dans le métamodèle, il faudra changerles templates, les analyseurs et l'interpréteur.Comment résoudre ce problème ?Une approche dirigée par les besoins.Nous allons utiliser Xtext. Ecrire du Lex ou du Yacc est une opération lourde qui n’est pas des plusaisées, Xtext permet d’éviter cette étape. A partir des descriptions de syntaxes et de templates9


fournies par l’utilisateur, un analyseur lexical et syntaxique est généré avec ANTLR. Un métamodèleEcore, correspondant à la syntaxe, est également généré dans Eclipse, ainsi qu’un plug-in d’édition.Une approche dirigée par la syntaxe abstraite.Dans ce cas, on utilise EMFText. Il suffit de fournir la syntaxe concrète ainsi que le métamodèle,<strong>pour</strong> générer un plug-in d’édition sous Eclipse.Une approche dirigée par les modèles.Cette solution requiert l'emploi de sintask, on y utilise exclusivement des modèles. L’approcheprônée par sintask est de rester dans Eclipse, et de demander à l’utilisateur de fournir son modèle desyntaxe concrète ainsi que son métamodèle. A partir de ces deux éléments, sintask génère le texte etle modèle correspondant. Dans la situation présentée ci-dessus, le problème réside dans le fait quetout repose sur le modèle de syntaxe concrète. Sintask permet donc de gérer ce dernier avec HUTNet permet donc de boucler sur le modèle afin de régénérer du texte.Une autre alternative est l'utilisation de GMF . L’idée est toujours de rester dans Eclipse et deconsidérer que tous les modèles sont indépendants les uns des autres. On manipule alors la méthodeQQC : quand, quoi, comment : quels sont les concepts ?, comment et quand les manipule-t-on ? etquand. L’utilisateur crée donc ces trois modèles et un mapping. On obtient ainsi un modèle degénération. Le tout nous fournira un plug-in d’édition dans Eclipse.ConclusionsJusqu’ici nous nous sommes intéressés aux langages textuels. Toutefois, il existe également desapproches graphiques (tel que Eclipse GMF).Exemple d’application :La société BlueAge a bien compris le principe de transformation des modèles. En effet, commenous avons pu le voir dans différents cours, cette société met à disposition de ses clients des solutionspermettant de convertir un modèle en code source.10


Semaine 3Présentation d’UML (Unified Modeling Language)UML est bien accepté dans de nombreux domaines (logiciel, business process), cependant il nel'est pas dans le domaine de l’embarqué temps réel. En effet il n’offre ni les éléments communs desADL, ni les moyens classiques de description de comportement (machine à états, réseau de pétri).Avec UML 2, il y a des ports et des classes structurées pouvant contenir des architectures, descomposants, des connecteurs, ainsi que de nouveaux comportements. Il y a également desdiagrammes structurels et comportementaux :• Use case : Première proposition des fonctionnalités que qu'offre un système. Il donneégalement les bornes d’un système, toutefois ce n’est pas le meilleur des diagrammes <strong>pour</strong>comprendre les exigences d’un système. Un « cas d’utilisation » est souvent un verbe quireprésente l’action effectuée par les acteurs.• Ports : Comment représenter les différents périphériques d’un PC sous forme d’UML ? Pource faire, on utilise la notion d’interface. Cette notion pose cependant un problème : elle nepermet pas de distinguer les rôles des différents composants. Les ports permettent decommuniquer avec un composant et de connaître son contenu.• Component : Un component est vu comme un élément exécutable du système. Il s’agit d'unespécification d’une classe. La notion de component est proche de la notion de d’ADL.• Connecteurs : Pour mettre en relation ces différents composants, on utilise des connecteurs.• Activités : Ce diagramme représente des séquences et des actions. On peut y spécifier desinterruptions lors d’une action.• Machine d’états: Ce diagramme représente le cycle de vie d’un comportement.UML est un standard, mais comme ses différents outils ne représentent pas obligatoirement lamême chose de la même manière, les interprétations peuvent être différentes selon le domaine. Il ya donc des manques dans UML. Ce dernier aurait besoin d’un moyen plus précis <strong>pour</strong> décrire lesexigences, les phénomènes physiques ainsi que <strong>pour</strong> indiquer les flots de données.SysMLSysML est un profil d’UML. Il a été réalisé <strong>pour</strong> décrire des systèmes. Il n’utilise pas l’UML dansson intégralité mais il l’étend. Par exemple, il n’y a pas de diagramme de classes, de diagramme decomponents, ou encore de diagramme d’objets. SysML ajoute la notion de bloc ainsi que celle dediagramme paramétrique.La notion de blocIl s’agit d’un concept unique <strong>pour</strong> la représentation d’un élément du système ou de sa structure.Il peut s’agir de hardware, de procédures, ou encore de personnes.Ceci entraîne la présence de nombreux types de compartiments. Nous pouvons de plus spécifiernos propres compartiments avec leurs propres caractéristiques, telles que :11


• Les propriétés• Les opérations• Les contraintes (peu importe leur type)• L’allocation du bloc• Les exigences auxquelles le bloc répondLa notion d’internal block diagram.Il s’agit d’une structure interne au block en termes de propriétés. Cette structure ne tient pluscompte de la hiérarchie des blocks.Les portsDeux types de ports existent :• Standart• Flow portAutresIl existe d’autres types de diagrammes structurels tel que le parametric diagram. Il est possible deproposer un ensemble d’équations paramétrées dans différents types de langages, mais sans <strong>pour</strong>autant pouvoir en évaluer le contenu.Le diagramme d’exigence permet de collecter et d’organiser les exigences du système.Exemple d’application :L’utilisation d’UML n’est plus à démontrer, toutefois dans certains domaines comme dansl’automobile, UML montre certaines faiblesses. C’est ainsi que B2i a par exemple décidé d'avoirrecours à Sysml.12


Semaine 4IntroductionTrès souvent dans le monde de l’industrie, on ne gère pas un seul objet, mais plusieurs dizainesvoir des centaines de versions de cet objet. Il n'est plus question d'un seul un produit, mais d'uneligne de produits. Le but, ici, est donc de comprendre les concepts qui sont mis en œuvre lorsque l'ondéfinit une ligne de produits. Ce sont des idées de tous les jours que l’on tente de formaliser. On vaainsi essayer de mettre en évidence les « besoins », lorsque l’on souhaite définir une famille delogiciels.Mots-clésUne « ligne de produits logiciels » est un ensemble de logiciels, chacun avec ses caractéristiquesmais qui partagent des propriétés communes .Un domaine est un secteur de métiers caractérisés par un ensemble de conceptscompréhensibles par les utilisateurs de ce secteur.PréambuleLorsque l'on a besoin de décrire une ligne de produits associée à un domaine, on aprincipalement besoin d'outils permettant de décrire des différences et des points communs. Ladualité est simple à faire mais une fois sortie de cette dernière de nouveaux outils sont nécessaires.En définissant les concepts du domaine, on va raisonner à un niveau plus abstrait ce qui permetde gagner du temps. Il faut ainsi faire vivre ces concepts entre eux, décrire leurs variations les uns parrapport aux autres, et au final les implémenter <strong>pour</strong> que l’ensemble fonctionne.Ainsi, nous allons essayer de présenter successivement les étapes d'analyse, de conception etd'implantation.Les différentes approchesPremière approcheSi l’on souhaite modéliser un domaine, on doit utiliser un formalisme tel qu’UML, Ecore. Onutilise les concepts de ce formalisme <strong>pour</strong> définir la ligne de produits et à partir de ce dernier, onrentrera progressivement dans les détails, <strong>pour</strong> finalement en faire dériver une application.Généralement, la description du domaine à un élément de ce domaine se fait par transformation.13


Deuxième approchePar transformation, une grande partie du code sera générée, mais pas dans son intégralité, ilrestera encore à en faire. Si l'on travaille au niveau du code généré <strong>pour</strong> assurer la maintenance, onva perdre le couplage entre le modèle généré et le modèle. Une autre approche est donc de nemodéliser que le domaine et d’y faire les maintenances.Fabrique logicielleL’idée d’une fabrique logicielle est de construire au fur et à mesure des modèles de plus en pluscomplexes par assemblage de manière à construire des systèmes de plus en plus complexes.De quoi avons-nous besoin <strong>pour</strong> décrire une ligne de produits logiciels ? Il est indispensablede donner:• des fonctionnalités obligatoires• des fonctionnalités facultatives• des choix alternatifs• des dépendances entre les choixExprimer la variabilitéPour exprimer la variabilité, on utilise l’héritage et la généricité. Ces deux concepts des modèlesou des langages combinés permettent d’exprimer plus ou moins bien la variabilité. On utiliseégalement la programmation par aspect (évolution de la programmation par objet <strong>pour</strong> gérerl’intégration de choses orthogonales à un programme : par exemple si l’on souhaite ajouter des tracesà un programme en langage objet, il faut ajouter au début de chaque méthode la ligne de codepermettant de le faire. Ceci prendra du temps. On a donc inventé la notion de programmation paraspect (AOM)) on peut par ailleurs utiliser la notion de transformation de modèle qui ajoute denouvelles fonctionnalités, ou encore permet de modifier un comportement. On spécifie lestransformations à apporter par une transformation ad-hoc. La variabilité s’exprime également par lacomposition de modèles qui permet de fusionner différents modèles. Et enfin par le feature model,qui prend en compte les principaux critères de variabilité. Il en existe de nombreuses extensions.Exemple d’application :On constate que dans l’ensemble de l’industrie, le fonctionnement des systèmes est ainsi. Il suffitde voir les différentes gammes de voitures ou d’avions existantes. On peut citer par exemple, la 307de Peugeot qui existe au format classique, au format Turbo, au format CC, au format SW…. Pourchacun de ces formats, il est nécessaire de réaliser un modèle unique.14


Semaine 5IntroductionUne automobile est un système complexe. En effet, prenons l' exemple du clignotant. Au départ,un clignotant était un simple pivot relié à quatre lampes. A présent, un clignotant est bien plus quecela. Il met en œuvre de nombreux calculateurs reliés entre eux par des bus. Alors qu’avant,seulement 9% d’une voiture était constitué d’électronique, aujourd’hui ce <strong>pour</strong>centage atteint les40%. Il faut donc de plus en plus de mémoire, afin de réaliser de plus en plus de fonctions, alors quel’on demande de moins en moins de calculateurs. On est donc dans l'obligation d'optimiser ledéveloppement en mettant en place des méthodes plus sûres.L’ingénierie systèmeUn système est bien plus que la somme de différentes parties : il s'agit d'une combinaisonintégrée de plusieurs éléments, qui forme un tout répondant à des besoins. De plus, il serait restrictifde limiter un système à la somme de chacun de ses composants. L’ingénierie système est définie parle CMMI (Capability Maurity Model Integration). Il s’agit de la capacité à développer un système. LeCMMI est la référence industrielle tout domaine confondu par rapport à la maturité dudéveloppement. Échelonné de 1 à 5 avec au niveau 1, la présence de commentaires dans le code, etau niveau 5, le fait d’avoir réalisé une analyse des défaillances des composants. L’ingénierie dessystèmes est une approche interdisciplinaire. C’est un moyen de s’assurer que le système en cours deréalisation va correspondre aux attentes du client. Il faut <strong>pour</strong> cela documenter les exigences, avoirdes éléments qui permettent de suivre ce qui a été fait durant les phases de conceptions , valider lessystèmes, et considérer le problème dans son intégralité.Ingénierie des exigencesLe coût d’un problème est défini en fonction : du moment de sa découverte par rapport au cyclede production du produit. Plus le problème est détecté tardivement, plus il coûtera cher de lesolutionner. La question qu'il convient alors de se poser est : d’où viennent ces problèmes ? Sur dixfacteurs, le facteur le plus important (13%) est dû à des exigences incomplètes et encore cinq de cesfacteurs sont liés directement aux exigences.Les <strong>pour</strong>voyeurs d’exigencesLes exigences proviennent :1- du client2- du project manager3- de la qualité4- des testeurs et des développeurs5- de la fabrique15


6- des instituts de standardisationAvant tout, il faut comprendre les exigences exprimées par ces différents <strong>pour</strong>voyeurs, et être enaccord avec ces dernières. Dans le cas, où les <strong>pour</strong>voyeurs seraient amenés à changer leurs exigences,il faudra pouvoir gérer ces changements.Une exigence est généralement formulée sous la forme suivante :Une exigence est ainsi atomique.Types d’exigencesIl existe deux types d’exigences. Les exigences fonctionnelles et les exigences non-fonctionnelles.Les exigences fonctionnelles indiquent ce qu’un composant doit faire, tandis que les exigences nonfonctionnellesindiquent comment l’objet doit répondre aux besoins.Architecture de développementL’architecture de développement est une organisation fondamentale du système. On parle dedécomposition de l’architecture du système sous forme de composants. Ce sont également lesprincipes qui dictent sa conception et son évolution. L’approche architecturale permet de pérenniserle travail d’un ingénieur et de capitaliser le système créé. De cette manière, tout le monde part de lamême architecture et le project manager peut mieux comprendre la situation.Relation entre l’ingénierie des exigences et l’architecture de développementLes exigences du système définissent les bases de l’architecture système. Celle-ci identifie lesexigences du System Component qui, à son tour, définit les bases de l’architecture SC, les exigencesdu Hard, du mécanique, et du Soft.Mise en place de cette structureMême si l'on a identifié les différentes exigences, on ne les comprend pas forcement <strong>pour</strong> autant.On a <strong>pour</strong> cela besoin de connaître notre interlocuteur. On vérifie ainsi que les exigences n’ont pas deredondance, qu’il n’y a pas un manque d’informations ou bien encore de contraintes inutiles. On16


tente de réutiliser des exigences déjà mentionnées, on étudie leur faisabilité et utilité. On estime leurcoût et leur risque. Il faut qu’elles soient testables (Ce qui n’est pas testable est inutile). Par ailleurs, ilfaut documenter et mettre des attributs corrects. Et finalement, déterminer le niveau de criticité dulogiciel.Puis on développe l’architecture, en identifiant les cas d’utilisations et en établissant des liensentre le system et le system component.Pour réaliser ces différentes étapes, une équipe est nécessaire. Cette équipe est composée d’un:• Projet manager• Gestionnaire de la configuration logicielle• Responsable qualité• Chef de projet logiciel• Chef de projet matériel• Ingénieur d’exigence : il connaît l’ensemble des exigences, les négocie avec le projectmanager et met en place les priorités des exigences• Architecte : il analyse le système et identifie les facteurs d’impacts• Test manager• Ingénieur d’intégration : il joue un rôle clé, il connaît tous les aspects techniques ducomposant• Ingénieur de testDescription de la solutionL’approche fonctionnelle est définie par une entrée, une logique d’exécution, ainsi qu’une sortie.Il s’agit de l’entité livrée avec le produit. Une fonction peut être décrite de manière textuelle ougraphique. L’ensemble des fonctions est regroupé dans une librairie.Développement de la solutionComment décrire une solution qui correspond aux besoins ? Il faut <strong>pour</strong> cela évaluer desscénarii en se demandant quels facteurs peuvent occasionner des problèmes. Puis, il convientd’établir des solutions tout en prenant garde aux impacts critiques (tels que les problèmes demémoire et de temps). C’est <strong>pour</strong> cette raison qu’identifier les exigences non fonctionnelles estimportant.Au final, notre exigence est satisfaite par notre solution. On vérifie que tel est bien le cas tout aulong du cycle en V. Pour cela, une exigence doit avoir un test, qui la vérifie, et une solution.Exemple d’application :17


L’exemple le plus parlant est celui de Toyota, qui après avoir constaté un problème defreinage sur ses voitures en bout de chaîne, a perdu 1,4 milliard d’euros. Il est clair que si cetteerreur avait été détectée dès le début, au final la facture aurait été moins lourde.18


Semaine 6IntroductionLors de ces derniers cours, un seul type d’approche a été présenté : l’approche statique. Plusieurssolutions ont été proposées, dont :• La génération de code : elle permet de construire un système à partir de son modèle• Le Reverse Engineering : il s’agit de l’opération inverse, on extrait automatiquement lemodèle d’un système• La transformation modèle à modèle : elle permet de migrer le modèle dans un espace plusadéquat.La seconde approche, que nous allons analyser, est l’approche dynamique. Le principe est basésur l’idée d’utiliser l’IDM comme outil de raisonnement, pendant l’exécution d’un système.Modèle à l’exécutionUn modèle à l’exécution permet de connaître le comportement et l’état d’un système en cours.Ces informations sont représentées de manière conforme au métamodèle et de manière simplifiée .L’erreur à ne pas commettre est de confondre un modèle à l’exécution avec un modèle exécutable. Eneffet, le modèle exécutable est un modèle dont on peut simuler le comportement, il ne reflète pas lecomportement d’un système en cours d’exécution.Les buts d’un modèle à l’exécution sont multiples :• Il permet de savoir si le système a bien le comportement attendu.• Il est possible de tester des événements ainsi que leur conséquences, sans les réaliserconcrètement.• Il est également possible d’adapter le système directement depuis le modèle.Il est ainsi possible durant l’exécution d’un système, qu’il s’auto-reconfigure (self-reconfiguration),qu’il s’optimise par lui-même (self-optimization), ou encore qu’il se répare tout seul (self-healing).Afin de rendre un modèle d’exécution disponible, plusieurs méthodes sont possibles :Tout d’abord, on a la possibilité de fournir simplement le métamodèle du modèle attendu ausystème. Celui-ci réalisera le système à partir de ces données.Une autre manière consiste à permettre au système exécuté de créer lui-même un modèleconforme à un métamodèle. Le système sera lui-même conforme au modèle qu’il aura créé. Ainsi unecertaine réflexivité est mise en place.Les applications d’un tel système sont multiples. Par exemple, dans le cadre de l’IHM, le systèmepeut s’auto-adapter lors de l’apparition d’un nouveau périphérique d’interaction.Exemple d’application :PauWare est un outil en Java qui permet d’exécuter des machines à états. Il récupère égalementle code exécuté <strong>pour</strong> afficher la machine à états lui correspondant.19

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!