Discussion :

[PeteMitchell]

Et bien, quel débat passionant.

Pour ma part, je vois UML comme un outil pour projet important séparant Analyse, Conception et Développement.
Le but recherché, ou en tous cas, celui que je pense déduire d'UML, est la possibilité de faire une analyse par une personne et de fournir les résultats à une autre personne capable de les intepréter, d'en faire une deuxième étude en vue de la conception et de la proposition d'environnement technique.

Je ne vois pas vraiment l'utilité d'UML sur des projets de 2 - 3 personnes car les documentations normalement présente (Cahier des charges ...) sont suffisantes en général. Et puis, moins on est nombreux, moins on se prend la tête avec les docs, il faut bien se l'avouer, rédiger un cahier des charges après la développement est courant et honteux, mais pas toujours de notre ressort ...

Pour revenir sur UML, sur un gros projets avec des analystes, qui sont en contact avec les clients, puis des concepteur / developpeur qui développent les briques de l'application, il est indispensable d'avoir une modélisation standard, facile à comprendre afin d'appliquer immédiatement les modifications necessaires.

Imaginez le cas où l'on doit corriger un existant. UML sert d'une part à modéliser l'existant, mais aussi à l'analyser, le diagnostiquer et modeliser les modifications. Il est donc indispensable d'avoir cette documentation.

Juste pour revenir sur le MCD (leger équivalent du diagramme de classes pour UML), c'est le seul document systématiquement fait pour chaque projet, et c'est regrettable dans le sens où quand on arrive sur un projet existant, il nous manque souvent la logique de l'application, un simple diagramme d'activités ou d'états ou même de séquences peut nous éviter bien des problèmes de compréhension.

Donc oui, UML ca s'utilise, bien souvent c'est couplé à un logiciel permettant la génération automatique de code, et pour les projets enormes, ca sert de cahier des charges, de compte rendu de diagnostique etc...

[Cian]

Bonjour,
J’ose me mêler à la conversation.

Il faut Surtout pour un professionnel!

Car ne l’oublions pas, Merise et Uml ne sont que des outils.

Attention, Merise est quand même une méthode

[ericlemoustic]

Pardon, effectivement Merise est aussi une méthode.

[bibiodp]

Je pense qu'il ne faut pas comparer UML et MERISE, ca serait comme comparer une BMW et un moteur de Mercedes (la belle métaphore...) : ils jouent dans la même catégorie mais n'ont pas le même rôle. UML n'est pas une méthode mais plutôt un langage de formalisation. MERISE est une méthode reposant sur son propre langage Je reviens à mon poste précedent mais pour comparer UML et MERISE il faut passer par une méthode utilisant UML : MACAO (méthode développée par J-B Crampes).

[vux]

Salut,
j'ajoute ma petite contribution à cette discussion assez intéressante.

ericlemoustic:

Pour mon expérience, je dirais que UML est plus simple à mettre en œuvre que Merise. Merise ne s’adresse qu’à des informaticiens (essayer de montrer un MCD à un MOA).

Je ne suis pas d'accord, j'ai toujours réalisé mes modèles de base grâce aux MCD de Merise, et après 5 minutes d'explications, tout le monde est capable de lire un MCD (même des personnes n'ayant aucune compétence en informatique).

Par contre il est évident que réaliser le MCD est beaucoup plus compliqué.

Par contre pour UML je dirais plutot le contraire, je pense qu'il est plus adapté au niveau opérationnel, alors que merise est plutot adapte au niveau conceptuel.

Mais en général dans mes projets je me sert des 2 (Merise pour les MCD + la description des processus, UML pour la partie classes sequence et deploiement).

En tout cas je pense que le plus important reste la méthodologie.

voilà
@+
vux

[Tsubasa]

Je dirais qu'on utilise UML que pour certains projets. C'est à dire des projets orientés objets.

De part mon expérience je peux vous dire qu'une bonne modélisation UML, entraine un codage en fermant les yeux. Le code c'est plus qu'une formalité.
Par contre je n'utilise pas tous dans UML. J'utilise les diagrammes de contexte, les cas d'utilisation, diagramme de classes, diagrammes de séquence et d'état si nécessaires.
Cependant je m'arrache toujours les cheveux avec les diagrammes de séquence, ne serait-ce que pour modéliser des boucles, des if ... Toujours obliger d'ajouter 2 3 trucs à ma sauce.

[Cian]

Cependant je m'arrache toujours les cheveux avec les diagrammes de séquence, ne serait-ce que pour modéliser des boucles, des if ... Toujours obliger d'ajouter 2 3 trucs à ma sauce.

Dans ce cas, les nouveautés UML2.0 te faciliteront le quotidien :
http://uml.developpez.com/cours/u2_sequence/

[chess]

Un petit mot pour remercier Cian (enfin je crois), pour avoir modifié ma question initiale en sondage. Ca a eu pour effet de relancer le thread et permet d'avoir une lecture clair sur les utilisateurs d'UML et la façon dont ils s'en servent.

Même si je ne participe pas, je continue venir lire les différents posts (je suis averti par mail ).

[edch37]

Bonjour,

J'apporte ma petite idée sur le débat. Moi personnellement j'aurais plutôt tendance à ne pas mettre MERISE et UML en position d'opposition. pourquoi ?
UML est très interessant pour une Entreprise ou autre dans le cadre d'une modélisation Objet cependant à partir du moment ou actuellement nous avons pour la plupart des SGBD de type relationnel au final MERISE revient avec Le MPD pour pouvoir travailler avec le schéma de la base de données.
A mon humble avis il faut les garder tout les 2 car pour moi à l'heure actuelle elles sont complémentaires(la phase UML étant quand même plus importante si le choix est UML).

[Casp]

bonjour à tous,

je suis étudiant en IUP ISI (ingienerie des systèmes informatiques) et durant ma formation nous faisons de nombreux projets. Pour la plupart de ces projets nous devons faire une partie conception (normal) et pour la faire nous utilisons le langage UML.
Grâce à cette conception claire, il est d'utant plus facile de développer son projet.
De plus UML propose de nombreux diagrammes significatifs pour décrire l'ensemble des fonctionnalités d'un projet

[MATHON]

Bonjour,

Je viens ajouter mon grain de sel à cette discussion intéressante.

Je développe des applications Struts/EJB/JSP. Personnellement j'utilise UML pour documenter les classes "techniques" gérant des aspects essentiels des applications (authentification, autorisations, pagination des gros volumes de données, accès au SGBD ....). En revanche, le développement des classes nécessaires au fonctionnement d'un écran suit souvent un schéma directeur commun à tous les écrans. Je décris ce schéma directeur avec UML mais ensuite, un ersatz de diagramme de séquence sous forme de tableau suffit largement pour comprendre comment marche telle ou telle fonctionnalité. L'avantage est de pouvoir produire une documentation relativement concise par rapport à un document farci de diagrammes volumineux.

Les clients pour lesquels je travaille ont rarement envie d'investir dans un outil UML payant , ils préfèrent le bon vieux traitement de texte. Cela dit, ils sont rassurés de savoir que les développements "vitaux" de l'application sont documentés de manière standard via UML.

Mis à part ce type de fonctionnement mixte, il ne m'a jamais été donné l'occasion de participer ou de gérer un projet entièrement en UML. J'ai le sentiment que ceci est réservé aux gros projets et aux services informatiques internes. En gros, à court terme, utiliser exclusivement UML coûte trop de temps. En revanche, il me semble qu'à long terme cela doit en faire gagner à condition de bien gérer.

A propos de gestion, je me demande comment on peut gérer la synchronisation de la modélisation UML et des développements en parallèle lorsque les outils sont incapables de générer autre chose qu'un squelette de classe ??

J'espère que je n'ai pas été trop long

a+

[esteban]

Salut,

moi je voudrais dire que UML, je ne m'en sers pas tout le temps, et surtout pas pour l'intégralité du projet car dans ce cas là, je passerai plus de temps à écrire des diagrammes UML qu'à coder.

Néanmoins sur des grosses entités (gros packages java...) où on bosse à plusieurs, on a forcément des diagrammes UML de classe pour comprendre de quoi on cause.

Dans l'analyse, on a aussi beaucoup les diagrammes de séquence parce que selon moi c'est indispensable pour faire apparaitre les synchronismes entre processus et entités, les messages...

En fait, j'utilise UML uniquement pour le diagramme de classe et le diagramme de séquence dans mes documents d'analyse et quelques docs techniques pour les collègues.

Sinon, pour les MCD on reste à Merise, il n'y a pas de raison de changer...

Pour finir, je voudrais dire aussi que le plugin omondo eclipse-uml pour eclipse est très bien et largement suffisant pour la majorité des besoins su développeur. Pas besoin d'investir dans une licence à 2000 Euros pour écrire des diagrammes de classe et générer le code automatiquement, sauf si on a un projet énormissime.

Enfin, c'est mon point de vue.

[bitou]

le plus important dans un projet de logiciel.
c'est de savoir ce que veut réellement l'utilisateur ou la MOA

l'interet est la, UML permet de décrire la demande, tu peux ainsi la formaliser rigoureusement. Ca va t'apporter des fondations en bétons pour le déveleppement car ca t'offrira une colle parfaite pour que les developpeur comprennent les besoins des clients ou utilisateurs.

perso j'aime bien les metaphores avec le genie civil

[Cian]

Salut,
moi je voudrais dire que UML, je ne m'en sers pas tout le temps, et surtout pas pour l'intégralité du projet car dans ce cas là, je passerai plus de temps à écrire des diagrammes UML qu'à coder.

Ce qui revient à dire que tu passerais plus de temps sur la conception que le codage : pour moi ce serait plus sein.

[Casp]

moi je voudrais dire que UML, je ne m'en sers pas tout le temps, et surtout pas pour l'intégralité du projet car dans ce cas là, je passerai plus de temps à écrire des diagrammes UML qu'à coder.

salut, ben je ne suis pas trop d'accord avec toi, le codage dans un projet ne reprèsente que 20% du travail (si je me souvient bien du chiffre), la plus grosse partie étant la spécification et la conception qui sont les phases clefs pour le bon aboutissement d'un projet.

[esteban]

Salut,

je suis d'accord avec vous et c'est pour cette raison que je précise que sur des projets de petite taille ou de taille moyenne, il n'est pas question pour moi de tout analyser et écrire avec UML parce que la proportion deviendrait pour le coup carrément délirante. Si on peut rester dans le cadre des 80-20 % ca reste jouable, mais si on doit dire au client qu'on a passé 2 jours d'analyse et 2 jours à coder, je ne suis pas pour et dans la plupart des cas lui non plus.

Mon avis est qu'il faut trouver le bon dosage entre l'efficacité d'UML (surtout si on est plusieurs) et la lourdeur inhérente (si on est tout seul ou si c'est petit projet).

Je précise que je travaille en indépendant, parfois en collaboration avec d'autres indépendants et que mes projets sont de tailles diverses. Dans certains cas je suis amené à développer de gros produits en Java dans un environnement où je dois céder les documents d'analyse au client (grand compte) et là il faut biensur que je mette la gomme sur l'analyse et la doc, mais dans d'autres je dois simplement faire un petit algorithme ou une petite application pour une PME avec des moyens financiers limités.

[sebA]

Salut,

il n'est pas question pour moi de tout analyser et écrire avec UML parce que la proportion deviendrait pour le coup carrément délirante

Une petite question de philo: qu'est ce que la totalite? si on pouvait tout prevoir y aurait plus de version patch...

Enfin pour dire: on te demande un soft qui doit faire ca,ca et ca donc tu vas forcement "tout" analyser! Et pourquoi ne pas l'ecrire ou plutot le decrire avec UML. Il faudra forcement que tu le decrive a un momment ou a un autre.

Pour moi UML c'est tous les jours, je ne peux pas commencer un projet sans des diagrammes UML! UML me permet de formaliser correctement ce que l'on me demande et de proposer une/des solution(s). De plus Toutes les questions que l"on se pose lors de l'etude on se les posera pas pdt l'implementation. Il m"arrive frequement de passer une semaine ou plus juste pour savoir ce que je dois faire et comment je vais le faire. Et je trouve plus simple de gribouiller des bouts de papier plutot que de de coder comme un malade et au bout d"une semaine tout effacer et tout recommencer.

Le probleme de l'informatique actuellement est que l'on passe plus de temps a implementer qu"a reflechir, bilan on va de patch en patch et en redesign, tout ca parce qu"on a pas reflechi assez au depart. Et je ne suis pas dans le milieu universitaire ...


@+
Seb

PS: dsl, les accents etaient en option sur mon clavier

[startout]

Effectivement tu as raison... la phrase d'analyse est parfois trop baclé...
Kand on fait du codage direct sans réfléchir avant plusieurs problème peuvent se poser par la suite.

Pour corriger ou modifier, sans phrase d'analyse c'est plus difficile avec tout ce que cela engendre : perte de temps, d'argent, etc.

UML a tout de même un gros avantage d'après moi, c'est de pouvoir affiner les détails de l'analyse au fur et à mesure de l'avancer du projet et de revenir modifier (modularité) ... Contrairement à MERISE qui sépare les données, des traitements.

[ovh]

Bon je n'ai pas tout lu faut de temps mais voici au moins un dossier d'analyse UML + génération code Delphi assez complet (et en français ), pour répondre au besoin de doc du posteur initial :
http://www.reseaucerta.org/cotelabo/dev/delphipl/

[Otomoby]

Je ne suis pas étonné que UML soit un sujet de tant de passion. UML n'est pas une solution en tant que telle. Pourquoi dire que UML doit ou ne doit pas être utilisé, tout cela dépend de nos besoins.

Personnellement j'utilise UML dans toutes les phase d'un projet:

Etudes d'opportunitées: Use case - Diagramme de séquences/collaboration/Etat
C'est une phase conceptuelle où l'utilisation d'un langage commun facilite les échange avec les futurs utilisateurs du produit (pas seulement informatique). Attention à ce moment une documentation complète doit accompagner les diagrammes utiliser et ceci pour la phase suivante:

Conception générale: Quoi de plus simple que d'écrire un cahier des charges avec la documentation issue de la phase précédente !!! reste à le complèter avec le modèle de classes métier et la partie dynamique associée. Pourquoi un modèle métier ? Car ce n'est pas aux développeurs ou aux prestataires (SSII) de connaître et de modèliser le métier ... forcément c'est pas le leur ... chacun à sa place !
Et voilà pourquoi celles-ci ne pronnent pas à mon avis l'utilisation d'UML c'est une manière de se garantir la maîtrise du développement et surtout de la maintenance !!! Qui pourrais reprendre une grosse appli sans documentation avec des délais et des coût corrects ?!!! Personne !

Conception détaillées: Là, les développeurs peuvent enrichir le modèle pas le modifier. La différence est que l'on doit dans tous les cas retrouver le modèle d'origine sans manipulation. Et cela vaux aussi pour la dérivation dans un modèle relationnel: les règles de dérivation doivent pouvoir être remontées pour retrouver le modèle objet métier d'origine. Car une appli évolutive implique que son système de persistence (SGBDR ou SGBDO) soit construit de la même manière (cf des technologies comme JDO en JAVA).

UML sert à formaliser tous les documents "techniques" d'un projet. Aujourd'hui on se doit de faire des applications évolutives à moindre coût ... sans modèliser et documenter c'est impossible.
Formaliser permet aussi que tous les acteurs parlent le même langage et se comprennent ou en tout cas qu'ils essaient ... c'est toujours dur entre la maîtrise d'ouvrage(celui qui décide et paie) et le maîtrise d'oeuvre (celui qui réalise: SSII) les but étant pas souvent identique .
UML est un outil qui bien utiliser s'avère puissant pour contôler le cycle de vie d'une application.
D'autre part j'occupe fréquement les deux postes MOA ou MOE, et comme personne n'est irremplacable je peux affirmer qu'il est important d'utiliser un outil tel qu'UML ou OOA ou MERISE 2 etc ...

Voilà ! J'espère que celà aidera.

Moby