Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous

Identifiant
Mot de passe

Mot de passe oublié ?

Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Qui définit et maintient la norme UML ?

Le 19 avril 2009 à 21:37, par zin_rbt

48 commentaires

21PARTAGES

J'aimerais savoir si les innovateurs du langage UML étaient des développeurs ou bien des analystes concepteurs.

Merci d'avance pour votre réponse

Une erreur dans cette actualité ? Signalez-nous-la !

Votre nom : Votre e-mail :

Décrivez l'erreur que vous souhaitez porter à notre connaissance :

48 commentaires

Commenter Signaler un problème

Alec6

Membre averti

Le 07/05/2009 à 10:52

Ah ! La passion d'UML

Est ce que quelqu'un dans la salle est chargé de la capture fonctionnelle et de l'analyse métier ? Ca serait interessant d'avoir un retour d'expérience.

Savez vous que UML commence à etre utilisé par d'autres acteurs que les informaticiens, c'est à dire par les clients.

On en trouve dans
- l'architecture d'entreprise pour d'écrire qui fait quoi ou quand comment...
- en assurance qualité pour décrire des process et HACCP
- un peu en compta
- on y vient en bio
- etc...

Faire du diagramme c'est vieux comme le monde.

Ce qui est magnifique c'est quand le client parle le UML (et il a vite fait d'en comprendre les bases: diagramme de classe voir d'objets, use case, et d'activité). Pour les states ca va si on a affaire à des techniques.

Dans ce cas lui il parle et nous on dessine. Et ce petit dessin lui il est formel, comme une équation mathématique (exemple: Ton salaire=Brut*0.77 c'est bien claire

. C'est la mise en place du diagramme d'Analyse métier qui est géniale. Après le cycle logiciel se déroule facilement, sans paradoxe, et sans surprise.

La deuxième étape est celle de la conception (architecture du logiciel). J'utilise ca aussi pour la communication en équipe. En restant grossier, c'est juste histoire et produire des spécifications.

L'UML au niveau développement j'ai jamais vu. Dans les grands compte sans doute, pour des projets ultra documentés.

Il ne faut donc pas oublié que UML c'est un langage inter humain de communication. Et comme il est formel il peut etre transcrit pour code.

La réussite d'un projet informatique c'est surtout la maitrise de deux facteurs:
- la communication
- la complexité (diviser pour mieux reigner)

UML améliore la communication quand il est bien utilisé.

ypicot

Membre confirmé

Le 10/05/2009 à 16:04

Une erreur que je rencontre souvent, c'est le mélange UML (langage) avec UML (l'outil, que ce soit Together, Rose ou n'importe quoi d'autre).

L'utilisateur se pose davantage de question sur "comment mettre la bonne flèche" que sur "pourquoi relier ces deux classes". Il est ainsi prisonnier d'un outil qu'il maitrise mal, et donc il est dominé par l'outil.

En fait (mais c'est peut-être mon coté formateur de développeur, donc au contact avec des personnes qui ont peu/pas d'expérience en modélisation), je proposerai une approche en 3 temps.

1) Apprendre à modéliser, à s'abstraire du code, penser en terme de service rendu par l'appli plutôt que
L'outil : le papier et le crayon, avec un formalisme plus ou moins inspiré par UML ou un de ces ancètres. On est dans l'approche de cf1020, qui envoie paître le UML pur beurre.

2) Faire des petits dessins ou des analyses dans son coin, c'est bien, mais dès qu'il faut communiquer (ou reprendre ses notes, sachant que dans l'intervalle on a pu changer sa manière de dessiner), ça pose pb. Et c'est là où UML arrive sur son blanc destrier, proposant un langage *commun*.
on continue cependant avec le papier et le crayon.

3) Le papier et le crayon font des dessins "pas propre" (mais très rapides), et qu'on a du mal à les envoyer par mail.
C'est à ce moment-là *et pas avant* qu'on peut commencer à utiliser un logiciel, quel qu'il soit.

Bien souvent, passer directement à l'étape 3 conduit directement à la catastrophe. Un peu comme un enfant qui voudrait courir alors qu'il ne sait pas encore marcher à quatre pattes.

Bien sûr, il existe toujours des gens très intelligents qui comprennent la différence entre composition et agrégation rien qu'en utilisant Papyrus, mais ils ne constituent pas la majorité de l'espèce.

Yvan
qui utilise encore le papier et le crayon (ou plus exactement la fiche A5 cartonnée)

Hephaistos007

Expert confirmé

Le 11/05/2009 à 8:49

Relié au point 3), il y a également le fait qu'il faut rendre numérique la modélisation pour pouvoir l'exploiter informatiquement (e.g, vérifications et génération de code). Ce serait dommage d'avoir une modélisation complète d'un système sans pouvoir en retirer le moindre bénéfice lors de son développement non ?

Hephaistos007

Expert confirmé

Le 22/04/2009 à 11:17

Leur expertise était clairement centrée sur l'analyse et la conception.

Vlade

Inactif

Le 29/04/2009 à 17:36

Je pense qu'il faut plus claire sur ce sujet et bien distinguer les rôles.
La norme UML a été faite par des spécialistes métiers et non des développeurs. Les outils UML ont été fait par des spécialistes métiers connaissant UML et des développeurs. Les outils de générations de code à partir d'un modèle ont été fait par des développeurs.

Les innovations peuvent avoir eu lieu à chacune des étapes du logiciels, que ce soit en conception métiers on en implémentation. Il n'y pas de meilleurs idées chez les uns ou les autres, tous doivent travailler en équipe et c'est cela la meilleur idée

Hephaistos007

Expert confirmé

Le 29/04/2009 à 19:57

J'ai pensé que par "innovateurs", zin_rbt faisait référence aux pères fondateurs d'UML. C'est sur cette hypothèse que j'ai répondu en tout cas ...

Vlade

Inactif

Le 30/04/2009 à 11:47

Hephaistos007,

Parlons un peu des pères de l'UML alors

Avant 1996 il existait les méthodes Rumbaugh dite OMT, celle de Grady Booch dite OOD et celle de Ivar Jacobson dite OOSE. Une vrai pagaille toute ces méthodes, mais n'oubliont pas aussi la méthode meurise qui est une création française qu'a remplacé l'UML

OMT+OOD+OOSE ont mergé ensemble pour faire UML qui a vraiment été standardisé par l'OMG et Rational en 1996.
Les normes UML ont beaucoup bougées passant d'une version 1.0 en 96 à une version 1.5 en 2005. Avec la version 1.5 je pense qu'on a vécu l'age d'or de l'UML.
Arrive ensuite la période des disputes que l'OMG a eu tous les problèmes du monde a unifié et l'UML 2.0.
A ce moment un mouvement de fond émerge sous l'influence de certains

pour parler d'interchangeabilité de model au niveau de la structure UML. Omondo a été le premier en 2004 a poussé la promotion d'un métamodel unique et a adopté la structure UML de Rationale comme metamodel interne. A ce moment les outils Rational et Omondo ont eu les même internes. Ensuite ont suivi les autres tel Togethersoft et maintenant tout le monde fait de même avec l'utilisation du framework GMF.
Le constat était que la transformation de modèle entre outil était quasi impossible et seul l'utlisation d'un même metametamodel ( le MOF) permettrait une vrai interchangeabilité. Après de longue bataille ont est arrivé à UML 2.2 en Mai 2008 et à ce moment un truc bizarre. Nous avons plusieurs père génétique pour le même enfant

Ben oui, Ed Merks et son équipe EMF ont crée le EMOF qui a servit de base pour créer la Structure UML 2 dite le metamodel UML, tandis que d'autre ont défini ce que devait être la Structure et le mécanisme interne de la Structure UML. La Structure UML a été validé et vraiment développé par Kenn Hussey (d'ailleurs que tout le monde a oublié pourtant c'est lui qui l'a faite ce metamodel UML 2 qui est aujourd'hui UML 2.2 dans les labo d'IBM à Toronto).
Voilà les papas d'UML d'un côté l'innovation initiale a surtout été en terme de présentation graphique et signification des graphes avec les 3 amigos (Rumbaugh, Booch et Jacobson) ensuite l'innovation a été plus sur les couches basses du MOF avec Ed Merks et Kenn Hussey et l'équipe R&d Marcello, Lena et les autres en grande parti brésilien du lab de Toronto.
Il y a bien sûre des Français comme Jean Brézivin et son équipe et d'autre projet open sources de l'Inria. Mais à part le projet de Jean et ATL les autres n'apportent pas vraiment d'innovation technologique et sont des suiveurs du projet GMF.

Hephaistos007

Expert confirmé

Le 30/04/2009 à 14:55

Je ne vois pas très bien ce que vient faire EMF dans cette histoire, pas plus que Omondo, ni aucun autre modeleur UML. Ce ne sont que des choix d'implémentation. Idem pour la transfo de modèle, qui n'est aucunement lié à UML, ni à un langage particulier (ex : tu cites ATL).

bruno_pages

Modérateur

Le 30/04/2009 à 14:58

Bonjour,

l'arrivée de Microsoft dans l'OMG va sans nul doute avoir des conséquences, surtout que cela vient semble-t-il après le départ de l'OMG de la plupart des personnes qui sont à l'origine d'UML, et quand on sait que de plus les outils 'poids lourd' de la modélisation UML le font sur Eclipse/Java ...

Vlade

Inactif

Le 30/04/2009 à 18:02

Hephaistos007,

L'innovation est passé du côté graphique aux couches basses. Je veux parler de l'utlisation d'un métamodel standard et identique à tous les outils. Ceci a été rendu possible par EMF et par la transformation de modèle avec le projet ATL.

Commenter Signaler un problème