Bonjour,
j bosse actuellement sur UML Executable, j'arrive pas a comprendre la difference entre un modèle de calcul et un modéle d'execution
merci
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Modèle de calcul vs Modèle d'execution
Bonjour,
j bosse actuellement sur UML Executable, j'arrive pas a comprendre la difference entre un modèle de calcul et un modéle d'execution
merci
Lis ce resumé de thèse : http://www.supelec.fr/ecole/si/pages...ardebolle.html
Merci,
justement je bosse en colabaration avec cette fille :-)
Merci quand même ;-)
Ah bah désolé. Le monde est petit.
Mais sinon j'ai un brin de solution, ça pourrait aider les autres ;-)
un modèle de calcul est le modèle qu'on connait (modèle d'un système) fait par le développeur par exemple. le modèle d'execution quant a lui est le modèle qu'a le systèmes quand il est en execution, c'est a dire c un modèle qui sera composé du modèle de calcul qu'a définit le developpeur + le support d'execution de la plateforme (exemple sur un système embarqué: objets définits par le développeur + gestionnaire mèmoire + gestionnaire de communication...)
voila, toutes les remarques sont les bienvenues :-)
merci beaucoup
Bonjour !
Je viens de voir que vous avez cité mon sujet de thèse ! ;o)
Effectivement, le monde est petit
Bon, il est peut-être un peu tard pour répondre à la question, mais je vais quand même essayer (des fois que ça serve à quelqu'un un jour).
Alors, les définitions que tu as donné, GETah, ne correspondent pas à celles que j'ai, mais bon, il s'agit de recherche, c'est normal que les gens ne soient pas d'accord entre eux
Un peu de contexte, pour commencer : je travaille sur les modèles de systèmes, que ce soit des systèmes électroniques, logiciels, physiques, etc. En particulier, je m'intéresse aux modèles qui représentent le comportement de systèmes (et pas uniquement leur structure par exemple). Dans ce contexte, on a mis au point les définitions suivantes :
- Pour nous, un modèle de calcul est une description de l'aspect comportemental d'une méthode de modélisation. Par exemple, si vous utilisez des automates à états finis pour modéliser le comportement de votre système, alors le modèle de calcul associé à votre modèle est le modèle de calcul des automates à états finis (Finite State Machine - FSM). Si vous utilisez une méthode basée sur les flots de données synchrones, comme par exemple la méthode implémentée par Simulink, ou le langage Scade/Lustre, alors le model de calcul associé à votre modèle est le modèle de calcul flots de données synchrones (Synchronous Data-Flow - SDF). Il faut bien voir que lorsqu'un modeleur dessine le modèle d'un système, le modèle de calcul associé à son modèle de système est pour lui complètement implicite : c'est le modèle de calcul qui est implémenté par l'outil qu'il a l'habitude d'utiliser, comme par exemple Simulink, qui implémente SDF.
Si l'on part du principe qu'un modèle qui décrit le comportement d'un système est composé de différentes "briques" élémentaires qui, dans la façon dont elles sont agencées/connectées, donnent par combinaison une représentation du comportement du système, alors le modèle de calcul définit :
- ce que représentent les différentes briques élémentaires qui composent la description du comportement du système. Par exemple, ces briques peuvent être des états dans le cadre de FSM, ou des composants représentant des processus dans le cadre de SDF.
- comment ces briques communiquent entre elles, comment les données sont représentées. Par exemple elles peuvent communiquer via des évènements, via des flots de données, etc.
- comment ces briques se synchronisent (ce qui est souvent lié à la façon dont elles communiquent). Par exemple elles peuvent se synchroniser sur l'arrivée d'évènements, sur l'arrivée d'échantillons de données, sur une horloge commune, sur messages, etc.
- comment est représenté le Temps (s'il existe dans le modèle de calcul utilisé). Par exemple certains modèles de calcul représentent le temps par une séquence d'évènements discrets, alors que dans d'autres le temps est représenté par une ligne continue.
- comment est géré le contrôle : quelle brique a le contrôle à un moment donné, comment est-il passé ensuite aux autres, etc. Par exemple, dans le modèle de calcul SDF, les différents processus peuvent être ordonnancés de manière statique. Le contrôle leur est alors passé en respectant cet ordonnancement. Dans le modèle de calcul FSM, on peut dire, à la limite, que le passage du contrôle est représenté par les transitions.
- Nous avons défini un modèle d'exécution comme étant une spécialisation opérationnelle d'un modèle de calcul. Un modèle d'exécution définit en fait une façon d'exécuter un modèle de système défini avec un modèle de calcul particulier. Concrètement, un modèle d'exécution "explique" pas à pas comment exécuter le modèle de système.
Il peut exister différents modèles d'exécution pour un même modèle de calcul. Prenons par exemple le modèle de calcul à équations différentielles, qui est très souvent utilisé pour représenter le comportement de systèmes physiques. Il existe plusieurs manières d'exécuter des modèles de systèmes décrits par équations différentielles : il s'agit de réaliser l'intégration des équations et pour cela il y a par exemple la méthode d'Euler ou la méthode de Runge-Kuta. Ce sont des méthodes constructives, qui ne donnent dans ce cas particulier qu'une approximation du comportement défini par le système d'équations.
Lorsqu'un modèle de calcul est décrit de manière constructive et très détaillée, il peut être confondu avec le modèle d'exécution correspondant.
Voila. J'espère que ça répond à peu près à la question... ;o)
N'hésitez pas à me dire ce que vous en pensez, bien sûr, ça m'aidera à avancer !
@+ !
J'ai oublié de préciser le rapport avec UML (puisqu'on est dans le forum UML) !
Alors en fait, je vois UML comme une méthode de modélisation parmis d'autres. C'est une méthode assez générale, qui permet de modéliser la structure (diagrammes de classes, etc.) mais aussi le comportement (diagrammes de machines d'états, diagrammes d'activités, etc.).
En ce sens, il existe un modèle de calcul UML.
Le problème est qu'à l'heure actuelle ce modèle de calcul est assez mal défini : il reste des points de variation dans la spécification qui sont sujets à différentes interprétations.
Et autant la plupart des outils UML savent générer des structures de code (squelettes de classes, etc) autant il n'y a (quasiment) aucun outil UML qui sait générer du code exécutable (c'est à dire le contenu des méthodes des objets par exemple) à partir de diagrammes de comportement UML.
Voila.
Tout ça pour dire qu'il y a pas mal de travaux de recherche autour d'UML Executable en ce moment
Sinon, pour revenir aux définitions de modèle de calcul et de modèle d'exécution, il existe une autre thèse, antérieure à la mienne, qui définit ces notions d'une manière un peu différente : http://tel.archives-ouvertes.fr/tel-00011219/en/
Voilou !
Hum... UML c'est un LANGAGE de modelisation, une "convention" pour representer graphiquement des structures et des comportements. Ce n'est pas vraiment une méthode, dans le sens "guide de modelisation". On peut juste verifier que les diagrammes respecte les spécifications du langage.Envoyé par modelix
Votre explications sur les differents modeles (systeme,calcul,execution) me rappelle etrangement ceux du MDA:
modele systeme <--> PIM
modele calcul <--> PM
modele execution <--> PSM
Je vais me plonger un peu plus dans votre these qui m'a l'air rudement interessante
Oui, effectivement, tu as raison, j'ai mélangé les termes méthode et langage ;o)
Peut-être que le bon terme est "approche" dans le sens large c'est-à-dire qui désigne éventuellement un language, un/des outils et/ou une/des méthodes ?
Concernant PIM/PM/PSM (définitions données dans le cadre de l'approche MDA), oui, effectivement, cela ressemble mais il me semble que c'est un peu trompeur car tout dépend ce qu'on désigne par le terme système et par le terme plate-forme.
Je crois que dans le cadre de MDA, les définitions sont les suivantes :
- un modèle PIM est un modèle à très haut niveau d'abstraction, qui décrit le système indépendamment de la façon dont il va être implémenté. En gros, d'après ce que j'en comprends, il décrit par exemple les fonctionnalités du système, sans préciser si il sera implémenté avec la technologie J2EE.
- un modèle PSM est un modèle PIM transformé de manière à ce que chaque partie du système soit spécifiée en utilisant des constructions fournies par la technique d'implémentation. Si je reprends l'exemple, le PSM contiendra la description des EJB, etc.
- un modèle PM est un modèle d'implémentation. Toujours avec le même exemple, le modèle PM décrira ce qu'est un EJB.
La conclusion de ça, c'est qu'un système présentant les même fonctionnalités que celles décrites dans le PIM aurait pu être implémenté en PHP, et que le PM aurait alors été différent et donc le PSM aussi.
Si on fait le lien avec mes définitions, voici comment j'expliquerais la chose.
En fait, lorsque je parle de système à modéliser, il s'agit d'un système à construire (une fusée ou un logiciel par exemple).
Lorsque je parle d'un modèle de système, il s'agit d'une représentation abstraite du système, réalisée avec un langage.
Lorsque je parle d'un modèle de calcul, il s'agit de la façon dont le langage permet de représenter un modèle de système (à partir de composants, à partir d'états, etc.).
Enfin lorsque je parle d'un modèle d'exécution, il s'agit de la façon dont un outil execute un modèle de système décrit avec un langage (dont on connait le modèle de calcul associé).
En ce sens, si on est d'accord pour dire que "système" désigne un système à construire, pour lequel on réalise un modèle, alors la notion de Platform de PIM/PM/PSM n'a pas d'équivalent dans mes définitions...
Pour décrire un PIM, un PM et un PSM on va utiliser des langages de modélisation particuliers, qui auront chacun un modèle de calcul et un modèle d'exécution.
...
Bon. J'avoue que je n'avais pas encore réfléchi à faire ce genre de lien. C'est un exercice intéressant, je vais creuser un peu ;o)
Merci !
Je pense que c'est une conclusion un peu hâtive. Mais le rapprochement est intéressant.
Là je suis plutôt d'accord.
Salut,il n'y a (quasiment) aucun outil UML qui sait générer du code exécutable
Justement j'ai fait mon master la dessus et je commence aussi une thèse la dessus. donc je pense que dans ce sens UML est pas mal avance!
Ciao ;-)
Ok, je vois ca comme la description "boite noire" du systeme. Un peu du niveau Use-Case + Scenarios dans UML
Toujours pour rester dans UML, on serait dans les diagrammes d'activités,classes,collaborations,...
Ca serait une "projection" du système dans le monde "orienté objet" (une approximation de la solution idéale)
La c'est plus touffu. Ca serait un peu la "spécification" de UML. Ce qu'on a le droit ou la possibilité de faire avec le langage UML.
Ca serait une "machine virtuelle" capable d'executer de l'UML. En attendant que david GETah termine sa these, ca reste de de la science-fiction.
Mais ca m'ammene a une question: peut-on réellement faire la description exhaustive et non-ambigüe du comportement d'un systeme en UML ?
Je dis ca, car generalement dans mes SDS, je décris des "vues" du systeme (les fameuses vues 4+1). Mais la somme de ces vues n'est pas suffisante pour decrire completement le systeme. C'est un peu comme en dessin industriel: on ne peut pas modeliser tous les objets 3D avec seulement les 3 vues face/dessus/gauche. non ?
(NB: aspiriiiiiiiiiiiiiiine)
J'ai du mal aussi à appréhender la notion de modèle de calcul mais je ne pense pas qu'elle ai un quelquonque rapport avec la "spécification" de UML (qui est aussi un modèle). Par exemple, un diagramme d'état UML n'est rien d'autre qu'un système de transition (SdT). Un tel modèle s'utilise en passant d'un état à un autre en franchissant des transitions. Pourtant cette connaissance n'est pas inclue dans le modèle lui-même mais réside dans notre connaissance implicite que le modèle de calcul rend explicite. Enfin je pense...
En théorie si ton système répond à des exigences finies, sa modélisation est finie.
A noter que même si la notion de vue/facette/aspect est bien admises, les relation entre ces vues reste un problème très difficile et peu traité.
Mmm, non, C'EST le système. Physiquement je veux dire ;o)
Là il s'agit du modèle du système, quel que soit le langage de modélisation utilisé. Pour UML, le modèle du système est constitué de l'ensemble de tous les diagrammes qui le décrivent.
Non, ce n'est pas tellement la "specification" du langage de modélisation, c'est plutôt sa sémantique comportementale (qui n'est parfois pas décrite dans la spéc justement).
Oui, voila. En fait, dans le cas de UML, si on prend un diagramme d'état, il s'agit de la sémantique des Statecharts, le modèle de machines à état créé par Harel (http://citeseer.ist.psu.edu/harel87statecharts.html), sur lequel est basée la partie diagramme d'états de UML.
Oui, c'est un peu ça. ;o)
Par rapport à ces remarques, de mon côté je pense que non.
En fait un langage de modélisation a forcément un niveau d'abstraction plus élevé que celui de la réalité puisque justement il permet de modéliser, c'est à dire de donner une représentation de ce qu'est la réalité.
Il s'agit donc, lorsqu'on choisit un langage pour modéliser, de le choisir en connaissance de cause, ce qui signifie accepter que le modèle final soit, sur certains points choisis exprès (car sans intérêt par rapport aux objectifs pour lesquels on réalise le modèle), une approximation de la réalité. Il peut donc ne pas être exhaustif, mais cela doit être un choix.
En ce qui concerne UML, malheureusement, sa spécification est par endroits embigüe et à d'autres endroits avec des "points de variation" acceptés.
Conclusion : différentes personnes peuvent interprêter différemment un même modèle UML.
En conséquence, je pense qu'il n'est pas possible de faire la description non-ambigüe du comportement d'un système en UML...
Effectivement. Un framework aborde le problème de manière très détaillée (mathématique) : il s'agit de Rosetta (voir une description assez complète sur http://mint.cs.man.ac.uk/Projects/Ro...hip/sota1.pdf).
Je ne pense pas avoir remis en cause cela. C'est la définition même d'un modèle.
En fait, je me suis mal exprimé, je ne voulais pas parler des exigences (requirements) sur le système mais des choix qui délimitent le périmètre de la modélisation (par exemple avec le principe de granularité: ou s'arrête-t-on dans la décomposition ?). On voit bien sur mon exemple de granularité qu'il faut fixer des limites finies pour qu'un modèle soit utilisable.
Ca je suis d'accord. Encore et toujours le problème du fossé sémantique (the semantic gap) qui existe entre un modèle et la realité qu'il est censé décrire. De grosses erreurs viennent de là.
C'est ça! le modèle UML qui est soit disons le modèle de calcul d'un systeme est enrichie (le corp des fonctions et methodes des classes, les actions des noeuds, transitions de sa machine d'etat sont definies dans un language d'action qui remplace le C++ et Java!
Exact! mais pas tout a fait
c'est le but final d'UML !! mais ça serait interessant plus pour les systemes critiques tel que les systemes embarqués temps réel des centrales nucleaires, voitures...
Merci,
Youps ! J'avais effectivement mal compris, désolée
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager