Tu peux développer ton idée? Parce que là c'est moi qui ne suis plus! Les 9 niveaux de Boulding je les vois bien, les s/systèmes de production et de pilotage aussi, mais j'ai du mal à raccrocher avec tt ce qui précède :?Citation:
Envoyé par hegros
Version imprimable
Tu peux développer ton idée? Parce que là c'est moi qui ne suis plus! Les 9 niveaux de Boulding je les vois bien, les s/systèmes de production et de pilotage aussi, mais j'ai du mal à raccrocher avec tt ce qui précède :?Citation:
Envoyé par hegros
Justement c'est ce que je cherche à éclaircir plutôt à explorer.Citation:
Envoyé par TheLeadingEdge
La transformation de modèle tel qu'on en parle avec UML concerne, mais je peux me tromper, surtout des transformations techniques en fonction de l'application qu'on en fait(documentation, génération de code, reverse ingénierie...) mais avec le méta modèle et le méta méta-modèle ce n'est pas encore très clair en tout cas les 9 niveaux de Boulding (plutot la de la moigne)reste modélisable en UML ou encore mieux en utilisant un méta-modèle ( ce qui revient à écrire un dsl avec atl par exemple?) ou partir depuis le départ avec un méta méta-modèle.
C'est aussi pour ma culture d'informaticien :mrgreen:
Je n'avais pas compris comme ça. J'avais compris que tu disais que le Meta modèle d'UML et les niveaux (Boulding ou LeMoigne c'est juste la formulation qui est différente) étaient la même chose. Forcément j'avais du mal...Citation:
Envoyé par hegros
Quoiqu'en y réfléchissant après coup, je me suis dis que ça pourrait peut-être le faire jusqu'au 7. Mais je n'ai pas vraiment creusé et il faudrait peut-être faire preuve d'imagination pour certains niveaux. Mais dans ce cas ça peut s'appliquer à autre chose qu'au métamodèle d'UML.
Je cherche si je retrouve mon ex. de la ''théorie générale des systèmes'' pour mettre un jpg. parce que le lien que tu donnes est plutôt avare d'explications.
En parlant du metamodel et meta metamodel c'est vrai que l'on en oublie l'essentiel qui la mise en oeuvre d'une démarche à l'aide d'UML et des vues. :oops:
Vues des cas d'utilisation, logique, d'implémentation, de déploiement et des processus. Chaque diagramme couvre une ou plusieurs vues. Dans l'approche d'UML Structure du Model il n'y a plus de séparation entre les vues et les mêmes élements peuvent être utlisé dans plusieurs diagrams voir et dans différentes vues.
Par exemple une classe peut être dans un classe diagramme mais aussi dans un usecase diagramme, un compoment diagramme etc...Le découpage traditionnel entre diagramme existe plus vraiment. C'est une volonté de l'OMG et d'IBM de faire évoluer l'UML dans ce sens.
Les diagrammes Structurels que sont: Class, paquetage, objets, composant et composite structure sont dans le même metamodel et peuvent être utlisé avec des diagrammes comportementaux : diagramme de usecase, etat transition, activé ou des diagrammes dynamiques : séquence diagramme, communication.
Je dirai que l'UML devient transversale et non plus en approche top down avec UML 2. Cette transversalitée est encore accentué avec UML 2.2 et la normalisation des métamodel au niveau de l'OMG.
La validation du model valide tous les élements de tous les diagrammes et de toutes les vues en même temps grâce à un mécanisme interne qui est une sorte de moteur xmi de validation dtd. Le moteur de validation utilisé est celui du plugin UML2 qui est aussi celui qui a été validé par l'OMG lors de la spécification UML 2.2.
Citation:
Envoyé par vlade
La validation concerne un méta modèle d'après ce que j'ai compris et il y a l'air d'avoir différents niveau de validation et ce n'est pas clair encore.
La validation, pour te reformuler, concerne la vérification d'un fichier XMI soit il est bien formé selon UML ou selon celui qu'on utilise en "maison" et alors on peut dire qu'il est validé.
C'est un niveau de validation, il doit en exister d'autres que je cherche à 'découvrir'. La preuve par le code par exemple en utilisant les modèles n'est pas du tout le type de validation dont tu parles, les exemples de type de validation de modèle si tu en as d'autres avec le code par exemple, bienvenue.
Re,
Je ne remet pas la main sur le schéma des processeurs, je met déjà la représentation canonique du niveau VII de LeMoigne en attendant.http://theleadingedge.developpez.com...mique 7-94.jpg
Je pense que le système des validations pourrait être représenté comme ça. C'est un début et trés simpliste, juste pour voir si on est sur la même longueur d'ondes. A voir par la suite comment y superposer le méta modèle.
Niveau I UML.
N II Boite noire qui transforme un flux d'informations en diagrammes UML
N III Système opérant.
- Ensemble de opérations modifiant les informations permettant de construire les diagrammes.
- Doit aussi refuser certains comportements de façon autonome. (régulation)
N IV Système d'information.
- Ne traiter que du XMI en entrée ...
- ... et ne générer que du XMI conforme, les 2 nécessitent la présence d'une DTD et ca dépend du SI qui informe le SO. Ce n'est pas de la régulation.
N V Système décisionnel. Il existe des règles (Méta-modèle)
- Analyse le flux d'entrée et déclenche certains traitements du SO fonction de état courant des informations permettant
de construire les diagrammes. (décision)
N VI SI. L'état courant des informations permettant de construire les diagrammes devient permanent. (Mémorisation.)
N VII Coordination (là j'ai du mal ... :?)
- Synchronization des diagrammes (?)
Niveaux VIII (IA) et IX (entropie) NA je pense
Merci cette transposition pose assez bien les choses et c'est un bon début je trouve
C'est intéressant que tu parles de xmi au niveau 4 je le verrais plutot au niveau 6 tandis que pour le niveau 7 je te rejoins tout à fait par rapport à la synchronisation des diagrammes mais il y a surement d'autres choses encore pour chacun de ces niveaux à explorer avec le méta méta-modèle ou un méta modèle :roll:
on finira bien par localiser et voir ce qu'est la validation du modèle et quelle partie concerne particuliérement la validation modèles/code c'est peut etre le niveau 9 ?
ce n'est pas sûr mais quand vlade parle de structure de modèle UML il ne veut pas dire par là qu'il informatise et automatise seulement les diagrammes de ce type (les statiques/structuraux comme le diagramme de classe) et qu'il ne traite pas les autres comme les dynamiques ou d'architectures ?
Puisqu'à ma connaissance il y a une topologie des modèles UML :statique,dynamique,architecture,usage,temporel...
Je ne connait pas les travaux de LeMoigne, mais je pense que cela n'est pas directement en rapport en avec l'ingénierie des modèles discutée ici. En fait, il me semble que les travaux de LeMoigne visent l'analyse et la modélisation de SI complexe, et ne s'intéressent pas directement aux langues (ou langages) utilisées pour le faire. Or, précisément, l'ingénierie des modèles se focalise uniquement sur les langages sans se soucier du pourquoi de leur existence et de leur utilité. D'ailleurs, l'ingénierie des modèle reste une approche très générale, qui n'est pas réservée aux informaticiens.
Pour en revenir au sujet, l'ambiguïté vient du mélange des genres, entre l'ingénierie des modèles d'une part, et UML d'autre part. Il y a des groupes de travail qui réfléchissent aux différents points de vues que l'on doit avoir sur un système d'information destinée à être implémenté dans une technologie objet, et qui proposent une spécification UML. D'autre part, il y a l'ingénierie des modèles, indépendante de toute cette agitation, qui stipule que la spécification d'un langage (UML, Merise, Tartanpion, etc.) doit être vu comme un méta-modèle et doit en conséquence être décrit dans un langage appelé le MOF (vu comme un méta-méta-modèle).
oui mais alors la validation qu'en est-il ? est-ce simplement une validation de la forme (du xmi) ? il n'y a pas de niveau différent de validation allant notamment jusqu'à la validation du code ? ou plutôt cela veut dire que MOF valide les modèles ce qui revient à valider du xml ? Ou écrire son langage de validation de modèle ?
j'avoue utiliser l'approche systémique pour appréhender mieux un peu tout ces concepts parce qu'entre le MOF, DSL, RTL et OCL c'est un peu le brouillard.
puis ce n'est toujours pas clair concernant la validation des modèles. Cela se dit déjà validation d'un modèle ou du code en utilisant les modèles ?
Encore désolé car plus je lis vos réponse plus je me rend compte que je répond plus la tête dans le guidon que de manière fonctionnelle :oops:
La validation du modèle est faite sur l'XMI au niveau du métamodel.
La validation du code est faite par le JDT java directement.
Comme le diagramme UML est synchronisé avec le model interne EMF, qui lui est synchronisé avec Ecore, qui lui est synchronisé avec la structure UML qui lui se synchronise avec le code java alors la validation du modèle et du code java marche à tous les coups sinon il y a un warning et l'impossibilité de clicker sur le bouton ok.
Par contre si on désire générer le code après la phase de conception alors c'est différent. Omondo a décidé de faire un travail minimaliste sur ce sujet. On crée juste les squellettes des applications, je veux dire les classifiers et ont laisse les développeurs implémenter les attributs et méthodes d'implémentation dedans à la main. C'est limité mais ca permet de bien séparé le travail de chacun et surtout de garder les même Id UML durant tout le projet.
C'est très important car si itération entre code et modèle en phase botom up (je veux model vers code et après code refactorer par le développeur vers le model) ont garde la tracabilité. La génération de code à partir d'un XMI casse la logique entre le code et le modèle. Il faut donc généré soit en synchronisation permanente, soit si en conception juste les classifiers.
Si toutefois cela n'est pas un problème de cassé cette logique ont a inclus AndroMDA chez nous. Le problèlme d'Andro c'est qu'il est juste xmi 2.0 et donc ne marche pas avec les derniers standards de l'OMG. On a dû donc bidouiller. On a bidouiller "assez gravement" :oops: afin d'utliser Ecore pour avoir un modèle valide pour le framework AndroMDA qui prend la main sur l'xmi en mémoire pour généré le code. Mais Andro même si c'est sympa je pense que garder une Id unique pour couvrir les cycles des itérations est plus important. Mais bon chacun fait comme il veut:calim2:
Il semblerai que certe parti de génération de code intérésse, pensez-vous qu'il est bon de parler plus en détail de cela et de la validation du code ?
mais justement la question est là concernant la validation. D'après vos dires cela concerne une vérification que les modèles sont bien formés conformément au métamodel UML dans notre cas c'est donc une vérification syntaxique.Citation:
Envoyé par Vlade
mais c'est tout ce que couvre comme validation omondo ?
Nommer pas de langage de programmation cela n'aide pas à moins que on part du principe qu'on peut considérer uml comme tel.Citation:
La validation du code est faite par le JDT java directement.
EMF c'est bien un méta métamodel comme MOF mais à un niveau plus technique et Ecore serait le module de sychronisation entre modèles UML pour avoir une structure(omondo?)UML qui génére ensuite du java alors la validation du modèle.Citation:
Comme le diagramme UML est synchronisé avec le model interne EMF, qui lui est synchronisé avec Ecore, qui lui est synchronisé avec la structure UML qui lui se synchronise avec le code java alors la validation du modèle et du code java marche à tous les coups sinon il y a un warning et l'impossibilité de
clicker sur le bouton ok.
si je comprends bien omondo est un outil pour faire du MDA puisqu'on pourrait considérer uml comme un langage de programmation.
ma question concerne plus la transformation de quelque chose écrit dans une guard d'un diagramme états transition en prédicat ou du z par exemple : a ^ b puis vérifier que le code colle avec ça.
mais comme je ne sais pas finalement ce que pourrait valider un outil omondo ou autre mise à part la forme des modèles (que c'est bien du uml par exemple), cela doit se développer pour la synchronisation inter-modèle sinon je suis complétement perdu :calim2:
Omondo n'a pas de règle validation c'est EMF, puis Ecore, puis UML 2 qui valident directement avec des règles prédéfini par Eclipse et l'OMG. A aucun moment Omondo n'intervient dans la définition des règles de validation.Citation:
mais justement la question est là concernant la validation. D'après vos dires cela concerne une vérification que les modèles sont bien formés conformément au métamodel UML dans notre cas c'est donc une vérification syntaxique.
mais c'est tout ce que couvre comme validation omondo ?
La vérification est sur la validité de l'XMI sur la dtd de réference en utlisant les règles de la structure UML et rien d'autre à ce niveau
La création du modèle graphique se fait par Omondo qui a crée un "glue" entre EMF+GEF, et ensuite l'étape d 'après c'est EMF qui valide cette création et envoie cette validation au modèle en mémoire. Après cela passe à Ecore qui revalide avant de redonner le tout à la structure UML. Il y a 4 étapes de validation du modèle. L'un est graphique avec le modèle EMF+GEf, ensuite c'est la vérification vis à vis de EMF qui appel à l'EMOF et enfin la validation de la syntax xmi et de sa sauvegarde. Ecore écrit l'xmi et la structure uml la valide toute seul. C'est vrai que parfois Ecore se trompe, mais on a corrigé toutes les erreurs directement en coddant en dure chez Omondo et en désactivant les appels aux méthodes buggés. Nous n'avons donc pas changé EMF mais réecrit les méthodes buggés chez Omondo.C'est là aussi qu'est la valeur car il y a un travail d'audit des couches basses d'EMOF
Mais comme expliqué plus tôt, tout est transparent car synchronisé en temps réel.
Ecore est égal un MOF et pas EMF. EMF est l'étape d'en dessous qui permet à Omondo de vérifier son modèle graphique.Citation:
EMF c'est bien un méta métamodel comme MOF mais à un niveau plus technique et Ecore serait le module de sychronisation entre modèles UML pour avoir une structure(omondo?)UML qui génére ensuite du java alors la validation du modèle.
Désolé c'est vrai que je me rend compte que ce qui me semble évident n'est pas du tout évident en realité :oops:
A hegros,
EMF n'est pas un méta-modèle, c'est juste un composant d'Eclipse dédié à la méta-modélisation, comme il existe des composants dédié au J2EE, au Mobile, etc.
Effectivement, la validation d'un modèle par rapport à son méta-modèle est assez simpliste. Tout simplement parce que certaine règles ne peuvent pas être exprimées de cette façon. C'est l'intérêt du langage OCL par exemple, qui va permettre de spécifier des contraintes dans un méta-modèle, et qui seront vérifiés dans les modèles. Une telle validation ne peut pas être basée uniquement sur le XMI. Un sous-composant de EMF est d'ailleurs dédié à cela : http://www.eclipse.org/modeling/emf/...ion#validation
En reprenant l'exemple du méta-modèle UML concernant le diagramme d'état-transition, un exemple de contrainte OCL serait de stipuler que deux états ne peuvent pas avoir le même nom :
Code:
2
3
merci pour ces précisions, il y a des éléments qui sont difficilement à savoir si l'ingénierie des modèles prends en compte ou pas, certains aspects comme la preuve par le code, pour rester dans un niveau de validation, par rapport à des modèles écrit avec un langage formel.
puis il y a la difficulté du contexte est-ce que le code source est existant sans modèle au préalable dans ce cas on fait une simple rétro-ingénierie et on remodele un peu puis on regénére un code source à jour ou alors il n'y a aucun code existant on peut utiliser une simple génération de squelette ou plus ou alors il y a du code existant avec un modèle préalable fait postérieurement etc...
puis la difficulté de validité la cohérence entre les modèles d'une part par exemple un diagramme de classe statique et un diagramme de séquence dynamique lié à un diagramme de cas d'usage et un diagramme d'architecture de déploiement et d'autres parts la validité de ce qui est généré au final (enfin ce qui est possible dans ce thread le code)
enfin, dernière question est-ce qu'il existe un méta modèle de validation de référence pour les éditeurs de IDE afin de voir la modélisation graphique( si c'est avec du UML c'est tant mieux ) de ce qui est entendu dans la communauté par validation des modèles lorsqu'on inclus le code comme modèle
Oui, EMF n'est pas un metamodel mais juste un model interne utilisé par Omondo afin de permettre la passerelle avec Ecore. C'est notre modèle graphique qui prépare à l'étape suivante.Citation:
EMF n'est pas un méta-modèle, c'est juste un composant d'Eclipse dédié à la méta-modélisation, comme il existe des composants dédié au J2EE, au Mobile, etc.
On rentre dans la transformation de modèle multiples. C'est une alternative au modèle unique promu par Omondo. Pour moi cette approche n'a d'intéret que si on cible autre chose que UML.Citation:
Effectivement, la validation d'un modèle par rapport à son méta-modèle est assez simpliste. Tout simplement parce que certaine règles ne peuvent pas être exprimées de cette façon. C'est l'intérêt du langage OCL par exemple, qui va permettre de spécifier des contraintes dans un méta-modèle, et qui seront vérifiés dans les modèles. Une telle validation ne peut pas être basée uniquement sur le XMI. Un sous-composant de EMF est d'ailleurs dédié à cela : http://www.eclipse.org/modeling/emf/...ion#validation
Mais si on cible java alors c'est une usine à gaz car la synchronization en temps réel rend ce projet inutile. D'ailleurs je me demande si ce projet sera encore maintenu. Il faut savoir que beaucoup de projet Eclipse sont juste dévellopé par une ou 2 personnes. C'est des sujets de recherche et bien souvent ils disparaissent avant d'arriver à maturité; Ce projet à mon avis va disparaitre mais bon on verra bien :roll:
Omondo a décidé d'abandonner l'OCL car UML 2.2 n'a pas de régle bien défini. Un élement UML est unique mais il peut être utlisé dans autant de vue qu'on vue. OCL est difficilement implémentable. OCL va disparaitre avec UML 2.2 c'est une quesi certitude, il faut donc passer à autre chose. Je dis pas que OCL est pas une bonne idée, juste que l'OMG ne l'a pas pris en compte lors de l'implémentation d'UML 2.Citation:
En reprenant l'exemple du méta-modèle UML concernant le diagramme d'état-transition, un exemple de contrainte OCL serait de stipuler que deux états ne peuvent pas avoir le même nom :
De plus en UML 2.2 ont peut rajouter des contrainstes directement à la racine de chaque élément. C'est pas l'OCL mais bon ca fait le boulot en partie. En résumé l'OCL et UML 2.2 c'est un vrai bordel aujourd'hui :(
Si le code source existe alors il faut le reverser pour créer un modèle. J'ai répondu à un poste sur ce sujet dans ce forum sur: http://www.developpez.net/forums/d55...g-accessibles/Citation:
il y a la difficulté du contexte est-ce que le code source est existant sans modèle au préalable dans ce cas on fait une simple rétro-ingénierie et on remodele un peu puis on regénére un code source à jour ou alors il n'y a aucun code existant on peut utiliser une simple génération de squelette ou plus ou alors il y a du code existant avec un modèle préalable fait postérieurement etc...
Il y a un modèle de validation XMI de la structure UML que propose le plugin UML 2 d'Eclipse. a part cela pas d'autre validateur que je connaisse et qui respectent les dernière normes UML 2.2Citation:
dernière question est-ce qu'il existe un méta modèle de validation de référence pour les éditeurs de IDE afin de voir la modélisation graphique( si c'est avec du UML c'est tant mieux ) de ce qui est entendu dans la communauté par validation des modèles lorsqu'on inclus le code comme modèle
Il y la notion de validité vis-à-vis d'un langage/formalisme (cela rentre dans le cadre de l'ingénierie des modèles) et d'autre notions de "validité" comme par exemple la preuve dans les langage formels. Mais cette dernière notion n'est pas lié aux éléments du langages, mais à des analyses que l'on fait en s'appuyant sur le langage, nuance. Par conséquent, cette notion là de validité qui existe pour certains langages (ex: le B) et peut être inexistant dans d'autre (ex: le CSS), n'est pas une préoccupation de l'ingénierie des modèles.Citation:
Envoyé par hegros
Reprenons le fil rouge de ce topic. Le langage UML (cad le méta-modèle UML) indique qu'un diagramme d'état-transitions contient des états et des transitions entre ces états, et n'autorise pas deux états à porter le même nom (Cf. contrainte OCL). Lorsque tu vas créer un diagramme d'état transition pour modéliser les feux tricolores, tu vas considérer un tel diagramme uniquement "valide" si il n'y a pas de transition réflexive par exemple. On comprends bien que cette notion de validité dépends du contexte d'utilisation d'un diagramme d'état-transition, et ne concerne pas la définition du langage UML en soi. Ton diagramme EST valide (au sens langage) car il respecte bien la langue UML, mais n'est pas valide par rapport à une analyse qui vise à détecter des transitions réflexives.
Comme je l'ai déjà dit, tu peux prendre le problème de deux façons. Soit tu modifie le méta-modèle UML en ajoutant une contrainte OCL pour interdire les transitions réflexives. Dans ce cas, tu viens de définir ton propre langage, appelons-le UML-FT (Uml pour les Feux Tricolore). Soit tu ne touche pas à UML, et tu développe un programme spécifique qui prend en entrée un diagramme d'état-transition, et qui indique en sortie si oui ou non, ce dernier est valide pour les feux tricolore, cad si il ne contient aucune transition réflexive.
Pas compris la question.Citation:
Envoyé par hegros
Alors ça c'est un tout autre problème, qui n'appartient pas non plus à la méta-modélisation en soi. D'ailleurs, si tu considères le méta-modèle du langage CSS ou HTML par exemple, cette notion de cohérence n'existe pas. C'est une caractéristque propre à UML qui définit 13 diagrammes, comme autant de vues différentes sur un même système. En fait, le problème de la cohérence se pose dès qu'un langage offre des vues. Du coup, ce n'est pas un problème de la phase de méta-modélisation, mais un problème qui devra être réglé par l'environnement qui permettra de modéliser.Citation:
Envoyé par hegros
Pas compris la questionCitation:
Envoyé par hegros
J'ai compris que UML définit 13 diagrammes ressemblant à ce que tu as posté plus haut avec le diagramme d'état transition et aussi que OCL permet d'une certaine manière la spécification et validation de modèle et n'est pas lié au XMI. Et que l'ingénierie des modèles se concentre sur les langages notamment sur les méta méta-modèle comme MOF
Est-ce que vous avez des sites à conseiller pour les notions de validité de langage/formalisme qui entre dans le cadre de l'ingénierie des modèles autant si vous connaissez un site qui montre une mise en oeuvre de validité avec le langage B/UML qui nous soit accessible.Citation:
Envoyé par Hephaistos007
Et encore merci pour tout le temps que vous voulez bien passer à donner des réponses sur le sujet.
Quel débat !
Merci pour cette belle discution (oui, je sais, mon post n'est pas très utile... mais je tenais à dire que j'avais aprécié la discution, voila :) ) !