Discussion :

[loic20h28]

Salut ..

j'aimerai bien m'aider pour me donner tout les process de developpement d'uml et quelles sont les plus utilisées ? et quelles sont les etapes à suivre pour chaque process? merci.

J'ai pas tous compris ce que tu demande car c'est pas toujours écrit en un bon français.

Qu'entend tu par process??
En gros, tu cherche des tutoriel sur uml??

[hegros]

j'aimerai bien m'aider pour me donner tout les process de developpement d'uml et quelles sont les plus utilisées ?

UML n'est pas un processus de développement. Des processus de développement utilisent UML pour certaines activités grande différence.


RUP(processus de développement) est très complet pour ce qui concerne l'utilisation d'uml, il y en a d'autres de connus comme le modèle en Y, je te laisse faire la recherche.


Quand aux étapes du processus le mieux est de télécharger un poster du process sur internet et de le graffer sur son mur.

[supzero]

salut ,
une bonne source : http://uml.developpez.com/

[gigosup]

Salut ..

j'aimerai bien m'aider pour me donner tout les process de developpement d'uml et quelles sont les plus utilisées ? et quelles sont les etapes à suivre pour chaque process? merci.

Salut,
J'ai pas bien compris votre demande, mais il est fort probable que tu veux soit :
- Les 9 diagrammes d'UML, alors si c'est le cas, zerosup a déjà donné un lien dans notre présent site.
- Si tu veux par ta demande, les processus de développement, alors là, je peux t'offrir cette petite définition.

Grâce au principe d'élaboration des modèles, UML permet de mieux maîtriser la part d'inconnu et d'incertitudes qui caractérisent les systèmes complexes. Mais cet aspect méthodologique d'UML ne doit pas vous induire en erreur. UML est un langage qui permet de représenter des modèles, mais il ne définit pas le processus d'élaboration des modèles ! Qualifier UML de "méthode objet" n'est donc pas tout à fait approprié.

Une méthode propose aussi un processus, qui régit notamment l'enchaînement des activités de production d'une entreprise. Or UML n'a pas été pensé pour régir les activités de l'entreprise ; ce n'est pas DOD-STD-2167A ou CMM.

Les auteurs d'UML sont tout à fait conscients de l'importance du processus, mais ce sujet a été intentionnellement exclu des travaux de l'OMG. Comment prendre en compte toutes les organisations et cultures d'entreprises ? Un processus est adapté (donc très lié) au domaine d'activité de l'entreprise ; même s'il constitue un cadre général, il faut l'adapter au contexte de l'entreprise. Bref, améliorer un processus est une discipline à part entière, c'est un objectif qui dépasse très largement le cadrede l'OMA.

Cependant, même si pour l'OMG, l'acceptabilité industrielle de la modélisation objet passe d'abord par la disponibilité d'un langage d'analyse objet performant et standard, les auteurs d'UML préconisent d'utiliser une démarche :

* guidée par les besoins des utilisateurs du système,

* centrée sur l'architecture logicielle,

* itérative et incrémentale.

D'après les auteurs d'UML, un processus de développement qui possède ces qualités fondamentales "devrait" favoriser la réussite d'un projet.

Une source fréquente de malentendus sur UML a pour origine la faculté d'UML de modéliser un processus, pour le documenter et l'optimiser par exemple. En fin de compte, qu'est-ce qu'un processus ? Un ensemble d'activités coordonnées et régulées, en partie ordonnées, dont le but est de créer un produit (matériel ou intellectuel). UML permet tout à fait de modéliser les activités (c'est-à-dire la dynamique) d'un processus, de décrire le rôle des acteurs du processus, la structure des éléments manipulés et produits, etc...
Une extension d'UML ("UML extension for business modeling") propose d'ailleurs un certain nombre de stéréotypes standards (extensions du métamodèle) pour mieux décrire les processus.

Le RUP ("Rational Unified Process"), processus de développement "clé en main", proposé par Rational Software, est lui aussi modélisé (documenté) avec UML. Il offre un cadre méthodologique générique qui repose sur UML et la suite d'outils Rational.

Plus récemment, VALtech propose le 2TUP ("2 Tracks Unified Process", cf. "UML en action", ed. Eyrolles), un processus unifié (c’est-à-dire construit sur UML, itératif, centré sur l’architecture et conduit par les cas d’utilisation), qui apporte une réponse aux contraintes de changement continuel imposées aux systèmes d’informations des entreprises.

L’axiome fondateur du 2TUP a été le constat que toute évolution imposée au système d’information peut se décomposer et se traiter parallèlement, suivant un axe fonctionnel et un axe technique. A l’issue des évolutions du modèle fonctionnel et de l’architecture technique, la réalisation du système consiste à fusionner les résultats de ces deux branches du processus.

Bien qu’un processus universel soit une utopie, la capitalisation des meilleures pratiques, à travers une famille de processus unifiés (tels que le RUP et le 2TUP), devient donc une réalité.

[lepinekong]

Comme dit hegros UML n'est pas un process de développement. LE process de développement qui s'appuie allègrement sur UML est RUP.

RUP étant une marque protégée d'IBM Valtech a créé TUP qui n'est qu'une pâle copie de RUP mais depuis récemment leur fond de commerce n'est même plus TUP mais Scrum aka une méthode Agile (faudrait le dire à vos profs )

Maintenant UML peut aussi être utilisé à dose raisonnable dans Scrum et XP mais plus dans le sens de "Sketching UML" c'est à dire d'une ébauche pour échanger ou communiquer et moins pour faire un diagramme hyper précis de conception où toutes les 5 minutes quelqu'un va te faire remarquer que tu t'es trompé dans le formalisme!

[Vlade]

J'aimerai apporter un peu plus d'information sur le sujet d'utilisation des méthodes agiles et de l'UML.

Le vrai dilème aujnourd'hui est de savoir qu'elle approche utilisé entre un MDE (model driven development) dans lequel le model drive le developement et une methode scrum / agile dans laquelle l'itération permanente entre donneur d'ordre et développeurs drive le developpement.

Pour RUP, ou TUP ou MDE le modèle UML est la phase de receuille des besoins et ensuite par transformation on va générer le code. Ensuite le projet à une documentation et les développeur code jusqu'au delivery. A ce moment on regarde ce que cela donne par rapport aux besoin initiaux et les diagrammes UML sont là pour tout vérifier.

Dans les méthodes agiles / scrum le code n'est pas généré à partir du diagramme UML et donc il n'ya pas de transformation d'UML vers le code. Les besoins sont définis avec ou sans UML, le code tappez à la main. Le problème est de permettre des itérations multiples si on fait de l'UML entre le code qui est tapez et les besoins qui évoluent.

Avec un peu de recul et comme les méthodes agiles ont commencées il y a maintenant plusieurs années, je dirai que l'UML est utilisé de manière beaucoup moins importante qu'apparavant. La place stratégique d'UML dans un projet a été perdu toutefois l'UML en amont des projets est toujours respecté. Pour moi la documentation directement dans le modèle apporte un grande lisibitlité au modèle, et l'approche de la métamodelisation avec UML 2 et les règles métiers peuvent aujourd'hui être décrite dans UML.. L'utilisation des profiles via les stéreotypes apportent aussi une touche personalisable type DSL ce qui permet de décrire aussi les processus métiers.
C'est à la limite de la bidouille car les informations manquantes graphiquement à UML sont remplis à la main directement dans le metamodel, donc dans le modèle non graphique. C'est valable en UML car accepté par le metamodel officiel de l'OMG donc pourquoi ne pas l'utiliser !!

[lepinekong]

RUP et Scrum sont tous les deux itératifs. Il ne faut pas croire que RUP c'est du waterfall sauf que malheureusement les gens qui se contentent de supercialités n'ont pas pris la peine d'étudier RUP dans les détails.

RUP met beaucoup l'accent sur UML contrairement à Scrum parce que RUP a été très formalisé par ceux qui ont créé UML et cela sur des centaines de pages mais dans l'esprit Scrum n'est pas si éloigné de RUP, simplement son message est plus dépouillé et paradoxalement plus clair pour les gens parce qu'ils ne prennent justement pas la peine de lire RUP.

Les promoteurs de Scrum ou XP sont en grande partie des architectes comme Martin Fowler et la modélisation n'est absolument pas exclue de leur démarche ce qui est exclu c'est de faire toute la conception de l'application et de la figer une fois pour toute avant de commencer à développer autour ce qu'ont tendance à faire de purs techniciens non férus de process de gestion de cycle de vie.

[souviron34]

Avec un peu de recul et comme les méthodes agiles ont commencées il y a maintenant plusieurs années, je dirai que l'UML est utilisé de manière beaucoup moins importante qu'apparavant. La place stratégique d'UML dans un projet a été perdu toutefois l'UML en amont des projets est toujours respecté.

Ce que je me tue à dire un peu partout sur ce forum (et avec quoi je me bat avec des clients potentiels régulièrement)...

UML n'est qu'un langage, voire une mode (selon moi) et ne fait rien vraiment pour l'élaboration d'un bon produit..

C'est un formalisme comme un autre..

Et la "déification" qui en a été faite est une absurdité..

Mais nous en avons déjà longuement discuté ailleurs



Il est bizarre autant qu'étrange que au bout de 40 ans d'applications de méthodes aussi variées que diverses, qui chacune se disait "révolutionnaire" et "résolvant les problèmes", il n'y ait pas plus de plomb dans la cervelle pour finir par admettre que la conception de logiciel est une activité à risque, artisanale, et a priori créatrice et non "industrialisable" au vrai sens...

Et que, comme nous l'avons déjà dit maintes fois avec B.A.F. entre autres, penser que l'on peut faire quelque chose d'exceptionnel avec des gens ordinaires est tout simplement du "wishful thinking" au même titre que parce que quelqu'un a une console MIDI tout le monde peut être JM Jarre ou les Pink Floyd...

C'est réellement étrange que le monde de l'informatique n'arrive pas à se rentrer ça dans le crâne....

[Vlade]

Le RUP n'a jamais été itératif a part dans l'esprit des gens de Rational !!
Un projet itératif veut dire que tous les gens de l'entreprise l'utilise c'est à dire chef de projet, modeleurs, architectes, développeurs et donneur d'ordres. Or combien de dévloppeur ont le droit de modéliser, ou connaisse UML assez bien pour le faire ? Je dirai que l'expérience montre que les développeurs ne modélise pas même dans un process RUP. On peut toujours dire que RUP est mal utilisé mais cela fait 10 ans maintenant que cela existe et donc il n'y a pas d'excuse possible sur le temps nécéssaire à l'adoption d'une nouvelle méthodologie.

L'UML peut être itératif si utilisé sans model driven or le MDE est le concept sur lequel s'apuie RUP.

Ce que je me tue à dire un peu partout

Oh non Souviron 34 il faut pas souffrir à cause de l'informatique, il faut en profiter et se faire plaisir des bonnes choses qu'elle apporte

UML n'est qu'un langage, voire une mode (selon moi) et ne fait rien vraiment pour l'élaboration d'un bon produit..

Oui, l'UML n'est qu'un language et croire que si on fait de l'UML ont doit aussi faire du RUP est une erreure

Et la "déification" qui en a été faite est une absurdité..

aujourd'hui l'UML n'a plus cette déficication que vous décrivez. Le problème est qu'on passe d'un extrème a un autre c'est à dire soit tout le monde fait de l'UML soit on en fait plus du tout. Et aujourd'hui je vois surtout que les gens n'en font plus du tout et c'est pas bon non plus !!

Il faut un UML agile, donc petit qui s'insére dans une démarche agile sans essayer de la guider. L'UML doit se plier au contrainte de la démarche Agile/Scrum sans vouloir que le MDD génère du code afin de se focaliser sur la documentation du projet, le recuille d'information, la spécification des contraintes, le travail en équipes etc....

[Jack Sparrow]

RUP et Scrum sont tous les deux itératifs. Il ne faut pas croire que RUP c'est du waterfall sauf que malheureusement les gens qui se contentent de supercialités n'ont pas pris la peine d'étudier RUP dans les détails.

Tout ça m'a l'air bien compliqué quand on voit qu'UML est souvent utilisé plutôt comme un outil de communication (et dans ce cas, on ferait mieux d'utiliser des choses plus simples non formalisées).

A quand le user group des anti-UML ?

[souviron34]

A quand le user group des anti-UML ?

Commencerai-je à me sentir moins seul ??

[Vlade]

Tout ça m'a l'air bien compliqué quand on voit qu'UML est souvent utilisé plutôt comme un outil de communication (et dans ce cas, on ferait mieux d'utiliser des choses plus simples non formalisées).

A quand le user group des anti-UML ?

Et voilà on passe d'un extrème prenant UML comme le saint grale à un groupe anti-UML
Pourquoi pas trouver le juste milieu ?

[lepinekong]

Le RUP n'a jamais été itératif a part dans l'esprit des gens de Rational !!

Premiers mots de la première phrase de Wikipedia :
[ame]http://en.wikipedia.org/wiki/IBM_Rational_Unified_Process[/ame]

The Rational Unified Process (RUP) is an iterative software development process framework

Si tu ne crois pas Wikipedia j'ai le bouquin des fondateurs enfoui quelque part dans une de mes armoires mais j'ai la flemme d'aller le rechercher (où ils disent itérative ET incrémental)

Maintenant c'est normal que tu aies crû le contraire parce que comme je l'ai dit dans mon article (http://lepinekong.fr/rup-est-mort-vive-scrum-2/):

Scrum ne diffère pas fondamentalement du RUP originel sauf que les dérives organisationnelles ont transformé RUP en une bureaucratie assimilée à la méthode Waterfall plus qu'à une approche itérative. Scrum est en quelque sorte ce qu'aurait dû être RUP si RUP avait été compris dans le sens que les auteurs l'avaient conçu.

La faute de cette incompréhension provient sans doute de l'appropriation de la méthode par IBM, symbole de la lourdeur dans le monde informatique.

[hegros]

RUP est itératif parce que UP est itératif. RUP y ajoute tout le développement guidé par les modèles UML.


Voilà comment je verrais un process de développement : du scrum encadré par RUP avec des rétro-ingénieries UML en fin d'itération du code/architecture executable afin de partir de cette base pour la prochaine itération et ainsi de suite jusqu'à ce que le modèle soit celui que nous avons affiner et fait évoluer

[hegros]

Tout ça m'a l'air bien compliqué quand on voit qu'UML est souvent utilisé plutôt comme un outil de communication (et dans ce cas, on ferait mieux d'utiliser des choses plus simples non formalisées).

On pourrait avoir la source de ce que vaut "souvent comme outil de communication"


UML a été largement éprouvé dans l'industrie depuis bien des années cela ne veut pas dire que c'est facilement accessible pour un débutant. A bien des niveau écrire un programme en langage UML ou C# ou Java revient au même niveau d'accessibilité

[Jack Sparrow]

On pourrait avoir la source de ce que vaut "souvent comme outil de communication"

C'est l'impression qui m'est apparu avec l'utilisation d'UML dans plusieurs boites où j'ai été.

Avant d'être un langage utilisé lors de la phase de conception, je l'ai surtout vu être utilisé dans la documentation technique (pour moi, ça rentre dans la communication interne pour les développeurs ou les futurs développeurs). Les "schémas" sont souvent trop précis, trop technique, trop complexe et on perd la simplicité d'un schéma fait à la main ou sous visio que tout le monde saura comprendre et maintenir du premier coup.

Il y a certains types de diagrammes que je n'utilise ou vois presque jamais. Quand j'en vois un, je dois sortir un bouquin pour le comprendre.


Alors peut être qu'UML est mal utilisé ou peut être qu'il est utilisé dans un mauvais contexte. Mais c'est peut être parce que ce n'est "pas accessible pour un débutant" qu'on est dans ce cas (et finalement je crois que c'est mal utilisé par plein de professionnels)


--
Il y a quelque jour, j'ai dû mettre à jour une documentation avec un diagramme de séquence qui rentrait même pas dans une page. Autant dire que le diagramme était quasi-inutile et qu'un simple schéma avec les 4 états de base (du genre, drag&drop, upload, indéxation etc.) aurait été suffisant. Si j'en veux plus, je vais voir dans le code. J'ai l'impression qu'avec UML, on oublie de rester simple.

[souviron34]

+1000



Et c'est je crois pour la même raison que il y a tant de posts (et de conneries) débité(e)s à propos du Procédural vs Objet..

Un excellent marketing auprès de gens n'y connaissant strictement rien, qui d'un seul coup se croient persuadés que rien ne marchait avant et que CA c'est LA solution miracle...

Et que donc il faut n'utiliser que CA (comme CMMM, ou ISO, ou...)...




La réalité est que justement ça n'est qu'une manière de communiquer, qu'il y en a d'autres (la plus simple étant papier/crayon ou petit schéma Word), et que la "modélisation" devrait se faire sans outils particuliers...

Sauf qu'on a voulu en faire bien plus que ça... Et , forcément, ça ne marche pas.. (un de mes arguments dans un autre débat, que tu reprnd, était "si il faut apprendre un nouveau langage pour communiquer, et "modéliser" une pensée, alors c'est comme l'épéranto : à part ceux qui n'ont jamais rien appris, pour la quasi-totalité c'est tout simplement inutile ace qu'ils parlent déjà une langue, et ça ne fait que compliquer la communication puisqu'il faut que l'ensemble des gens apprennent cette nouvelle langue)

[Vlade]

Voilà comment je verrais un process de développement : du scrum encadré par RUP avec des rétro-ingénieries UML en fin d'itération du code/architecture executable afin de partir de cette base pour la prochaine itération et ainsi de suite jusqu'à ce que le modèle soit celui que nous avons affiner et fait évoluer

Je suis pas d'accord avec Hegros, désolé
Pourquoi RUP doit-il encadré Scrum ?
C'est un non sens et laissons nos amis scrumiens la liberté de faire comme ils veulent tout en faisant de l'UML sans RUP et MDD (sans Model Driven qui implique génération de code en top down du model vers le code, et aussi uniqument une itération au niveau modèle et non pas comme c'est le cas au niveau des projets Scrum au niveau code) s'ils le considèrent important

[lepinekong]

Citation:
Envoyé par hegros Voir le message
On pourrait avoir la source de ce que vaut "souvent comme outil de communication"

C'est l'impression qui m'est apparu avec l'utilisation d'UML dans plusieurs boites où j'ai été.

Avant d'être un langage utilisé lors de la phase de conception, je l'ai surtout vu être utilisé dans la documentation technique (pour moi, ça rentre dans la communication interne pour les développeurs ou les futurs développeurs). Les "schémas" sont souvent trop précis, trop technique, trop complexe et on perd la simplicité d'un schéma fait à la main ou sous visio que tout le monde saura comprendre et maintenir du premier coup.

Il y a certains types de diagrammes que je n'utilise ou vois presque jamais. Quand j'en vois un, je dois sortir un bouquin pour le comprendre.


Alors peut être qu'UML est mal utilisé ou peut être qu'il est utilisé dans un mauvais contexte. Mais c'est peut être parce que ce n'est "pas accessible pour un débutant" qu'on est dans ce cas (et finalement je crois que c'est mal utilisé par plein de professionnels)


--
Il y a quelque jour, j'ai dû mettre à jour une documentation avec un diagramme de séquence qui rentrait même pas dans une page. Autant dire que le diagramme était quasi-inutile et qu'un simple schéma avec les 4 états de base (du genre, drag&drop, upload, indéxation etc.) aurait été suffisant. Si j'en veux plus, je vais voir dans le code. J'ai l'impression qu'avec UML, on oublie de rester simple.

Les Grands Esprits se rencontrent, à propos de UML pour la Communication, je viens d'écrire hier soir un article sur comment j'ai fais pour rendre UML comestible même aux Utilisateurs et aux Managers (mais je n'ai pas prononcé devant eux le mot UML pour ne prendre aucun risque de les efffrayer !).



Eh bien ils en ont redemandé après ça

[hegros]

C'est l'impression qui m'est apparu avec l'utilisation d'UML dans plusieurs boites où j'ai été.

Avant d'être un langage utilisé lors de la phase de conception, je l'ai surtout vu être utilisé dans la documentation technique (pour moi, ça rentre dans la communication interne pour les développeurs ou les futurs développeurs). Les "schémas" sont souvent trop précis, trop technique, trop complexe et on perd la simplicité d'un schéma fait à la main ou sous visio que tout le monde saura comprendre et maintenir du premier coup.

Pour l'instant dans les boîtes où j'ai été c'est plus une utilisation pour les spécifications générales que pour la documentation (la documentation ce n''est pas une valeur dans le monde agile...)

Il y a quelque jour, j'ai dû mettre à jour une documentation avec un diagramme de séquence qui rentrait même pas dans une page. Autant dire que le diagramme était quasi-inutile et qu'un simple schéma avec les 4 états de base (du genre, drag&drop, upload, indéxation etc.) aurait été suffisant. Si j'en veux plus, je vais voir dans le code. J'ai l'impression qu'avec UML, on oublie de rester simple.

Exemple typique d'une erreur de conduite de projet et rejeté sur UML. Si tes diagrammes sont trop grands pour rentrer dans une page c'est que le découpage de ton application et/ou de ton plan de doc est foireux.