Discussion :

[NutsFou]

Bonjour à tous!

Je me permet d'apporter mon petit grain de sel sur quelques points :

1. UML n'est pas une méthode mais un langage duquel on peut se servir en appliquant l'une des diverse méthodes qui existent (RUP, 2TUP,...).
Chaque méthode varie dans la succession des schémas en fonction du but à atteindre.
Ex: 2TUP vise à développer parallèlement le fonctionnel et l'architectural. Il y donc 2 branches parallèles qui se rejoignent et cela implique donc une organisation spécifique des diagrammes mis à disposotion par l'UML.

2. Pourquoi un langage?
Pour une expression universelle. C'est beau, mais ça signifie quoi au juste? Eh bien, c'est un peu comme l'esperanto (en + efficace tout de même...) : le but est d'avoir une grammaire et une orthographe commune au delà des frontières et de la limite des entreprises.
De cette manière, peu importe le processus suivi, tu débarques sur un projet et tu comprends les schémas. C'est pas balaise, ça?! Après, il ne reste plus qu'à apprendre la méthode appliquée dans le cadre du projet.

3. Grammaire et orthographe en UML?
UML étant un langage, il est naturellement régit par certaines règles permettant de le structurer.
- Grammaire : Ce sont les diagrammes.
De même qu'en français, pour poser une question il faut inverser le verbe et le sujet et terminer par un :, en UML pour décrire le déroulement d'une activité (scénario), on dessine des acteurs et des objets avec leurs lignes de vie respectives et on décrit les flux des uns aus autres par des flèches continues ou pointillées.
- Orthographe : Eh bien ce sont les symboles utilisables dans chacun des diagrammes.
Un ovale pour un use-case, une flèche dont le trait est continu et dont la pointe est gros triangle pour indiquer un héritage, etc.
- Les deux ensembles : Tout bêtement, les symboles ne sont pertinents que dans un certain cadre.
En effet, le symbole du use-case n'a rien à faire dans un diagramme de classes : ça n'a tout bonnement pas de sens!
L'UML est donc l'art d'associer des symboles précis dans les limites d'un diagramme en vue d'exprimer un concept bien précis.

Conclusion :
Se mettre à l'UML est loin d'être inutile, même si on ne l'utilise pas directement et si on applique pas de méthode particulière. Pourquoi? Parce qu'il met à disposition des "UMLophones" des outils de langages qui permettent de structurer une idée, un concept.
Même en griffonnant sur le coin d'une nappe en papier au milieu d'un resto, un schéma précis et concis avec des symboles compris par tous est + explicite et permet d'aller + loin qu'en improvisant des flèches et des rectangles sans formalisme aucun.
Ce langage permet donc une certaine structuration de l'esprit, qui en + tend à être commune pour tous ses pratiquants, et qui permet de décrire à peu près n'importe quoi qui suit un processus dans la vie de tous les jours.

Re-conclusion :
Que des bonnes raisons de s'y mettre! (même si ce n'est pas à fond)

[Hibou57]

Bon, hé bien ça tombe bien... justement la question que j'avais envie de poser.

Ma première remarque n'a rien de technique. On entend partout parler d'UML, mais je n'ai jamais vu de code source d'application accompagné de shéma UML. Si au moins ces code étaient accompgnés de documentatio exaustive s'introduisant par une description de la globalité de l'application, ce serait déjà bien.

Mon avis sur UML est paradoxale, je comprends bien tout ce qu'il peut apporter en matière de compréhension et de communication, mais en même temps je le trouve lourd, et je n'aime pas ses redondance interne qui s'apparente quelque part à des ambiguité (quand on voit une chose représenter d'une certaine façon, et qu'on se dit qu'elle aurait put être représenter d'une autre manière, c'est perturbant... on se demande si on comprends bien, et on se demande pourquoi ce choix a été fait plutôt qu'un autre, mais on ne peut pas avoir de réponse.

Je vais shématiser mon parcours personel. Avant de découvrire le developement logiciel, je l'imaginais, je n'en avais aucun idée, je n'avais même jamais touché à un ordinnateur... mais c'est une chose que j'avais envie de connaitre (par curiosité scientifique). Quand j'ai eu un ordinnateur, c'est sous windows 3.1, avec QBasic... j'ai été ébais de découvrire que c'était la programmation. Je m'attendais à de la rigueure, des formalisme, des preuves de fonctionnement. Bref, je pensais que l'algorithmique était aussi « propre » que les science mathématique.

On dira, QBasic ce n'est pas une référence... mais dans les grandes lignes, je n'ai fait que trouver la même chose partout.

Donc depuis le tout début, j'avais l'intuition, et l'envie, de méthode d'expression stricte, parlante et abstraite.

Mais avec 10 ans de recul, le sentiment que j'en ai, c'est que le dévellopement, ce n'est que du codage, sans vision globale.

Alors même si je trouve UML trop lourd, je reconnais son apport *potentiel*. Le problème, je pense, est qu'il n'a pas été concus pour être ce qu'il y a de mieux (il n'a pas eu le processus de developement qu'il méritait), il a été concus pour faire plaisir à un ensemble de collaborateur, c'est à dire qu'il est un panier de tout est n'importe quoi (le consensus, c'est bien connu, n'est généralement satisfaisant qu'à cours terme... mais on ne pense malhreusement que dans le cours terme à notre époque, et pas seulement en informatique).

Je regrète qu'UML ne soit pas plus répandu, même si je ne l'aime pas. Malheureusement, les autres langage de représention, ou les autres méthodes (bien qu'UML ne soit pas une méthode) permettant de develloper avec clairvoyance, ne sont généralement pas applicable pour diverse raisons : Z est trop lourd et innadapté, VDM est mieux pensé que Z, mais VDM est propriétaire, UML est un panier de tout est n'importe quoi concus dans le but de faire un consensus qui n'était qu'un vision à court terme, BON (issu du monde Eiffel) est plus léger, plus claire, mais il est trop pauvre (comme le langage Eiffel d'ailleur, malgré qu'il ait des qualité appréciables).

Je me dit, personne n'utilise UML, même si tout le monde en parle... et je me dit aussi... ne pas utiliser UML, on peut le comprendre... mais ne pas documenter, c'est intolérable.

Personne n'utilise UML, mais il faudrait au moins faire des efforts avec la documentation!!! (fut-elle à la manière de l'auteur, pour peu qu'il introduise un peu sa manière en préembule du document).

Ca vous inspire cette remarque ?

[Ryan Sheckler]

Je regrète qu'UML ne soit pas plus répandu, même si je ne l'aime pas. Malheureusement, les autres méthode permettant de develloper avec clairvoyance, ne sont généralement pas applicable pour diverse raisons[...]

* se remet de son infarctus *

1- Ah non, non et non, UML n'est pas une méthode, c'est un langage : il te permet de t'exprimer graphiquement, de représenter graphiquement.

2- Une méthode qu'on peut coupler à UML, c'est le RUP. Et quand on dit méthode, je dirais personnellement que RUP est à UML ce que la grammaire est au langage naturel.

3- Le langage UML sans méthode (grammaire) est comme un langage naturel sans grammaire : tout et n'importe quoi. UML ? Oui, mais pas UML seul.

• Exemple : Une phrase, du langage naturel, sans grammaire : un c'est sans comme naturel grammaire langage.

4- Le langage UML est aussi ambigü que le langage naturel, je te l'accorde, mais tu n'as pourtant pas l'air de maudir ton français.

En conclusion :
Bref, si tu prends UML pour ce qu'il n'est pas, normal que tu ne l'apprécies pas (et par là tu ne l'apprécies pas à sa juste valeur).




Post-Scriptum 1 : dans l'entreprise dans laquelle je bosse, nous travaillons de plus en plus avec UML (et RUP et Hermes). Et quelques entreprises en collaboration aussi. (c'est mon petit vécu de la chose)
Post-Scriptum 2 : voir l'article d'un rédacteur de developpez.com.

[Hibou57]

Oops, coquille... comment j'ai put écrire une bourde pareille

... je suis pardonnable ou pas ? ...

... je m'en vais corriger de ce pas.

Je confirme : UML n'est pas une méthode, mais un langage de représentation et de description.

Avocat : mais à la décharge de mon client, j'aimerais attirer l'attention de madame la juge, sur le fait que mon client parlait alors « d'autres méthodes », il ne parlait donc pas d'UML, mais des autres astres de la même constellation (les méthode s'impose souvent au départ par des représentations standardisées, d'où l'abus de langage facile et seulement indirect).

Monsieur le juge répond à Madame la juge : ok pour la comparaison avec le français et d'autres langue vivante, mais là c'est toi qui « insulte » UML, parce qu'avoir les caracteristique d'une langue vivante (ambiguité et co), c'est tous le contraire de ce qu'on attend d'un langage formel. Donc tu confirme d'une certaine manière le reproche que je fais à UML.

Je veux bien aimé UML à sa juste valeur... si tu veux bien m'y aider

Par exemple, sais-tu s'il existe un sous ensemble d'UML moins ambigus, et qui filtrerai le 10% avec lequel en fait 95% du travail ?

Et ce qui a surement été un frein à la diffusion d'UML, c'est le fait que les environement UML sont souvent trés lourd (et que dire du prix des license). Je sais bien que les « vrai(e) pro » regarde souvent les autodidact avec une triste condescendence... mais ces autodidacte, par leur présence répartie, par leur nombre, et par le temps qu'il passe à communiquer, sont pour beaucoup de le succés ou l'insuccés de certaine chose parfois ... souvent en mal d'ailleurs, comme avec le C/C++ par exemple. Mais il faut en tenir compte quand même, et en ne visant que les grands compte, UML ne risquait pas d'être autre chose qu'un argument marketing : comme tous ce qui brille de loin et qu'on ne touche jamais (si tu me comprends).

Sinon, que pense tu de l'idée de déjà commencer à faire des efforts avec la documentation en générale ? Parce que quand je vois que 90% des codes je trouve ne sont pas plus documenté qu'avec quelque miséreux commentaires (soit trop ciblé, soi trop triviaux), et que le peu d'application documenté ne l'est pas dans sa globalité, je me demande comment dans ces conditions on peut espérer faire adoppter UML d'une large manière. Quelqu'un(e) qui ne documente même pas ses codes, je le/la vois mal s'interesser à UML.

Post-Scriptum 1 : merci pour le rappel du liens sur le cours
Post-Scriptum 2 : je vais me pencher sur HOOD, et je pourrai peut-être alors le comparer à UML

[yasinfo]

Salut,
L'interêt d'UML se résume surtout dans son utilisation dans les systèmes d 'information et (dans l'élaboration des cahier de charges ...).
Aussi, je tiens à préciser que UML est un langage qui facilite la communication et les négociations entre les différentes "personnes" impliquées dans l'élaboration d'un systèmes d'information.....
Il faut aller vers tt ce qui est standardisé !

[Joshua Beharia]

********La question est : Quel est l'interrêt de la rediger avec UML. Pour ma part, j'ai toujours fait cela en français, en ajoutant des diagrammes simples (forme basée sur les organigrammes) et avec des MCDs. ******

Salut,
L'interêt d'UML est surtout dans son utilisation dans les systèmes d 'information et surtout dans l'élaboration des cahier de charges.
Aussi, je tiens à préciser que UML est un langage qui facilite la communication et les négociations entre les différentes "personnes" impliquées dans l'élaboration d'un systèmes d'information.....
Il faut aller vers tt ce qui est standardisé !

Hello,
pour ma part j'utilise UML alors que je développe des systemes RT embarqués !
Il n'y a pas de domaines spécifiques à UML, tu peux utiliser ce langage pour tout !

[startout]

Ca devient compliqué. Juste pour parler de la nuance entre UML et une méthode de modélisation (Merise, etc...).

Si pour le prof de 'Methodologie des S.I.', UML n'est clairement qu'un outils ouvrant un eventail de diagramme, pour le prof qui nous enseigne l'UML, ca n'est pas le cas. Je suis d'ailleurs assez d'accord avec lui, dans le sens où finalement, les demarches pour produire les diagrammes est de même nature que celle utilisée dans les autres méthodes (captures des besoins, analyse, rédaction et représentation sous forme de schémas). Les nuances sont sur la forme de reflexion et la façon d'appréhender le probleme (structurée descendante,objet ou systémique). La nuance est d'ailleurs encore plus floue quand on compare OMT et UML.

Aprés discussion avec le prof de 'méthologie des S.I.', il s'averre que les réponses concernant ces nuances ne sont guere convaincante. Ca tourne autour du 'c'est comme ça', avec en arriere plan, un petit gout 'moi prof, moi savoir, toi eleve, toi ecouter'.

Loin de moi l'idée de mettre en conflit ces 2 profs, mais aprés discussion avec le prof enseignant l'UML, je partage son opinion concernant ce type de débat : Ce sont des discussions de principe et d'opinions.

Je vois bien de qui il est question dans ce post. J'ai eu ce prof. Il a beaucoup de connaissance mais dommage qu'il n'écoute pas

[Hibou57]

Loin de moi l'idée de mettre en conflit ces 2 profs, mais aprés discussion avec le prof enseignant l'UML, je partage son opinion concernant ce type de débat : Ce sont des discussions de principe et d'opinions.

Mais ceci n'empêche pas de pouvoir évaluer, mesurer, quantifier la pertinance et l'aisance à l'usage... non ?

[t_om84]

Je prends part à la discussion après avoir lu ces 5 pages, ainsi que le cours UML disponibles en lien.

Je suis un développeur junior, plutôt orienté vers la programmation python et la conception de logiciels. Jusqu'à mes exams de BTS IG, je n'avais jamais entendu, enfin je ne m'étais jamais attardé sur UML.

Il est vrai qu'au jour d'aujourd'hui, les annonces d'emploi préconisent l'utilisation d'UML. J'ai lu dans ce topic que certaines personnes se mettent à UML car c'est à la mode. En effet, personnellement, je peux dire que c'est vrai, mais d'un autre coté, si on veut répondre aux exigences d'une entreprise, il est nécessaire d'avoir des notions. Il est clait que comme tout langage, on ne peut pas apprendre en quelques heures de lectures intensives. Mon but, aujourd'hui est d'acquérir les bases d'UML. Pour cela je me lance dans un projet et je compte bien me servir de l'analyse UML pour le créer.

En attendant, j'ai encore quelques lectures à faire. Mais, j'espère que je ne vais pas dire de betises, j'ai un peu besoin de lumières, on parle d'UML vs Merise, je ne vois pas pourquoi, si j'ai bien compris, UML est surtout utilisé pour analyser la conception d'un programme, alors que merise sert plutôt à analyser une base de données.

Pour moi, lors de la planification de mon programme, je vais définir mes classes via UML, mais afin de créer mes bases de données, je vais utiliser merise.

Est-ce que je me trompe? ou est-ce que je mélange tout?

Merci

[vmolines]

Bon, hé bien ça tombe bien... justement la question que j'avais envie de poser.

Ma première remarque n'a rien de technique. On entend partout parler d'UML, mais je n'ai jamais vu de code source d'application accompagné de shéma UML. Si au moins ces code étaient accompgnés de documentatio exaustive s'introduisant par une description de la globalité de l'application, ce serait déjà bien.

Mon avis sur UML est paradoxale, je comprends bien tout ce qu'il peut apporter en matière de compréhension et de communication, mais en même temps je le trouve lourd, et je n'aime pas ses redondance interne qui s'apparente quelque part à des ambiguité (quand on voit une chose représenter d'une certaine façon, et qu'on se dit qu'elle aurait put être représenter d'une autre manière, c'est perturbant... on se demande si on comprends bien, et on se demande pourquoi ce choix a été fait plutôt qu'un autre, mais on ne peut pas avoir de réponse.

Je vais shématiser mon parcours personel. Avant de découvrire le developement logiciel, je l'imaginais, je n'en avais aucun idée, je n'avais même jamais touché à un ordinnateur... mais c'est une chose que j'avais envie de connaitre (par curiosité scientifique). Quand j'ai eu un ordinnateur, c'est sous windows 3.1, avec QBasic... j'ai été ébais de découvrire que c'était la programmation. Je m'attendais à de la rigueure, des formalisme, des preuves de fonctionnement. Bref, je pensais que l'algorithmique était aussi « propre » que les science mathématique.

On dira, QBasic ce n'est pas une référence... mais dans les grandes lignes, je n'ai fait que trouver la même chose partout.

Donc depuis le tout début, j'avais l'intuition, et l'envie, de méthode d'expression stricte, parlante et abstraite.

Mais avec 10 ans de recul, le sentiment que j'en ai, c'est que le dévellopement, ce n'est que du codage, sans vision globale.

Alors même si je trouve UML trop lourd, je reconnais son apport *potentiel*. Le problème, je pense, est qu'il n'a pas été concus pour être ce qu'il y a de mieux (il n'a pas eu le processus de developement qu'il méritait), il a été concus pour faire plaisir à un ensemble de collaborateur, c'est à dire qu'il est un panier de tout est n'importe quoi (le consensus, c'est bien connu, n'est généralement satisfaisant qu'à cours terme... mais on ne pense malhreusement que dans le cours terme à notre époque, et pas seulement en informatique).

Je regrète qu'UML ne soit pas plus répandu, même si je ne l'aime pas. Malheureusement, les autres langage de représention, ou les autres méthodes (bien qu'UML ne soit pas une méthode) permettant de develloper avec clairvoyance, ne sont généralement pas applicable pour diverse raisons : Z est trop lourd et innadapté, VDM est mieux pensé que Z, mais VDM est propriétaire, UML est un panier de tout est n'importe quoi concus dans le but de faire un consensus qui n'était qu'un vision à court terme, BON (issu du monde Eiffel) est plus léger, plus claire, mais il est trop pauvre (comme le langage Eiffel d'ailleur, malgré qu'il ait des qualité appréciables).

Je me dit, personne n'utilise UML, même si tout le monde en parle... et je me dit aussi... ne pas utiliser UML, on peut le comprendre... mais ne pas documenter, c'est intolérable.

Personne n'utilise UML, mais il faudrait au moins faire des efforts avec la documentation!!! (fut-elle à la manière de l'auteur, pour peu qu'il introduise un peu sa manière en préembule du document).

Ca vous inspire cette remarque ?

Exactement mon ressenti, c'est épatant

[Fleur-Anne.Blain]

Bonjour,


Cela va paraitre peut-être arbitraire ce que je vais dire mais dans les projets scolaires ou professionnels que j'ai pu faire cela se résume à ca:

UML: Pour la POO, si un langage objet est utilisé
Merise: Dès qu'il y a une BD qui entre en compte

Ceci dit, l'on m'a déjà contrainte à faire de A à Z certains projets avec UML...et quand je demande justifications auprès des supérieurs: No comment, ils ne savent peut-être pas pourquoi....c'est peut-être au goût du jour pour eux et c'est tout...

[Hibou57]

Ceci dit, l'on m'a déjà contrainte à faire de A à Z certains projets avec UML...et quand je demande justifications auprès des supérieurs: No comment, ils ne savent peut-être pas pourquoi....c'est peut-être au goût du jour pour eux et c'est tout...

Les supérieurs, en règle général, ne savent pas pourquoi ils (parfois elles) prennent telle ou telle décision... Ils (elles) font le plus souvent leur choix technique comme ils (elles) choisissent leur cravates (ou même leurs employées) : question d'image. Le chef veut d'abord avoir l'air d'un chef avant d'être compétent(e)... c'est là leur maladie (la psychiatrie a semble t-il plusieurs fois démontré que le sentiment de supériorité alter certaines capacités).

Pour ce qui est du choix d'utiliser UML ou Merise, selon les circonstances que tu cite, j'ai constaté exactement la même chose lors d'une formation.

Le choix de Merise a également, un temps, été dicté en france par une motivation chauviniste également.

... d'un autre coté, pour ce que je connais de Merise (je ne connais pas ces dernières évolutions), il faut reconnaître que cette méthode n'est pas trés adapté à l'objet... ou alors ce serait un peu comme faire de la POO en programmation purement structuré/procédurale. C'est possible, bien sure, mais avec un support dédié, c'est quand même moins barbant.

[Fleur-Anne.Blain]

Les supérieurs, en règle général, ne savent pas pourquoi ils (parfois elles) prennent telle ou telle décision... Ils (elles) font le plus souvent leur choix technique comme ils (elles) choisissent leur cravates (ou même leurs employées) : question d'image. Le chef veut d'abord avoir l'air d'un chef avant d'être compétent(e)... c'est là leur maladie (la psychiatrie a semble t-il plusieurs fois démontré que le sentiment de supériorité alter certaines capacités).

Ca sent les mêmes expériences que moi ( et ca ne fait que commencer).

[Hibou57]

Ca sent les mêmes expériences que moi ( et ca ne fait que commencer).

Vu ce que tu raconte, je crois que c'est quand même moins grave pour toi que pour moi... je ne te souhaite pas de vraiment connaître ce que j'ai connu : c'est une honte (mais la honte ne fait peur à personne dans ce pays).

Beh, bon courage pour toi quand même.

P.S. Si tu t'interesse à UML, je te propose de découvrire BoUML : http://bouml.fr/ ... c'est une assez bonne application, essaie, tu verra. C'est du free (c'est bien, même si ce n'est pas une garantie de qualité), beaucoup plus léger que RationalRose, ça évolu régulièrement (mise en conformité, correction de bug). Et en plus le developpeur qui a créé BoUML n'a pas pris la grosse tête hihihi.... j'ai eu quelque petits contacts par mail avec lui, et il est trés sylpathique (ne jamais oublié l'humain dans tout ces histoires).

Happy Modeling

[luminien]

Bonjour a tous !
Donc je réctifie, ce que j'avais deja ecri, en disant que c'est une méthode et non un langage aujourdhui je dirai que l'UML est un langage pseudo-formel
Cours UML

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
j'avais cité par rapport a un cours que j'ai eu, que c'est plutot 

une méthode qu'un langage :

Modelisation.pdf 

voila

[Invité]

Je vous conseille de regarder de très près le projet EMF d'Eclipse.

La modélisation, que ce soit en UML, EMF, XML ou autre permet aujourd'hui de gagner un temps non négligeable grace à la génération de code (java, html/jsp, fichiers de configuration, classes de tests, mapping hibernate...) et de documentation.

Le projet EMF propose 2 sous-projets très intéressants pour réaliser celà simplement et efficacement:

• ATL: Génération "model to model"
• JET : Génération "model to text"

En générant (et en regénérant à partir d'un modèle), vous garantissez de plus que votre documentation (et vos modèles) restent synchronisés avec votre application, et la décrivent au mieux.

Enfin, en utilisant les modèles pour le code, en plus de la doc, celà reduit les coûts liés au temps de modélisation.

[hed62]

Pour ajouter ma touche perso à ce post épique (je suis ingénieur d'études jeunement diplomé : j'ai peut être un regard différent...)

UML se répand de plus en plus en entreprises (5 stages différents, et 4 sont en UML+, 1 en Merise)

UML et certains diagrammes de Merise (MLD, MPD essentiellement) sont complémentaires pour moi.

Je ne pense pas que cela n'est pas une mode, ni un truc pour séduire le client : je suis actuellement sur un [énorme] projet de 15000jours homme , et UML est grandement utilisé, notamment les use case, les diagrammes de classes et de séquence, pour améliorer la communication :
- Chef projet - Client (UC)
- Analystes - Concepteurs (UC + diag classes)
- Concepteurs - Développeurs (le tout)

Sincèrement, sans ces diagrammes, impossibles de pondre du code correct dans un si gros projet.

J'ai cru lire "UML est informel". Je ne suis pas tout à fait convaincu ni qu'il soit totalement informel, ni qu'il soit réellement formel...

Hibou57 a dit : "Par exemple, sais-tu s'il existe un sous ensemble d'UML moins ambigus"
Pour ce qui est des contraintes qu'on ne peut exprimer purement en UML, il faut en effet ajouter un langage de spécifications comme OCL.

Pour le code généré derrière, oui je trouve qu'il y a encore du boulot... Mais ce n'est pas la faute d'UML

J'ai lu aussi que certains trouvent UML lourd. J'ai du mal à comprendre pourquoi vous avez ce ressenti : lourd par rapport à quoi ? Je préfère cent fois lire un diagramme de classes que du code source, même si c'est mon propre code et même si je dois passer 2h à faire le diagramme ! Maintenant, c'est peut être RUP que vous trouvez lourd... En ce cas je compare à Merise, qui n'est pas trop léger non plus

[Hephaistos007]

J'ai cru lire "UML est informel". Je ne suis pas tout à fait convaincu ni qu'il soit totalement informel, ni qu'il soit réellement formel...

En effet, UML est un langage semi-formel.

[hed62]

:-D

Heu... Par semi-formel, qu'entends tu ? Que certains aspects sont formels et pas d'autres ? Ou plutôt que certains arguments tendent à dire qu'il est formel, mais que d'autres tendent à dire qu'il ne l'est pas ?

Merci de m'éclairer sur ce point !

[Hephaistos007]

Disons que le langage UML est définit formellement par le métamodèle UML mais possède une notation semi-formelle en faisant usage de graphiques. Les graphiques ne présentent pas la rigueur d'un langage linéaire répondant à une syntaxe précise. Il est par exemple impossible d'effectuer des preuves sur des diagrammes UML.
Les diagrammes statiques sont évidemment moins concernés par ce manque mais les diagrammes dynamiques le sont. Comment s'assurer que tous les états sont atteignables dans un diagramme état-transition ou comment montrer que deux diagramme de séquence peuvent se "superposer" sans incohérence ? etc...

Rendre UML formel tout en conservant son aspect unifié est un vrai casse-tête. Mais il y a eu des essais.