Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Pour tous mes projets et de A à Z
Pour tous mes projets : processus partiel
Pour certains projet et de A à Z
Pour certains projets : processus partiel
Rarement
Jamais
Jamais UML, par contre toujours MERISE
Jamais UML, par contre parfois MERISE
Jamais UML, autre (précisez)
C'est quoi UML ?
Sans opinion
Ovh, le posteur initial te dis merci. Il n'a pas encore tout lu. En fait il est assez surpris du résultat. Ca demande relecture. Je pense avoir fait des progrés sur UML depuis mon post initial, mais c'est pas encore ça.
En tout cas, merci beaucoup pour cette exemple.
Vous avez dit UML ???
Pour avoir assez etudier UML en cours et pour avoir avoir bosser depuis 2 ans dans une grosse boite avec notamment certain TRES GROS projet déployés sur plusieurs dizaines de sites partout en france je peux vous dire que dans cette société je n'ai presque jamais entendu le mot UML !!!
Donc moi j'en conclu pour avoir vu les resultats de ces GROS projets déployés et développés sans analyse et bien que c pas joli joli......
Donc étudier et analyser des projets et programmes OUI mais avec UML pas forcement.....
Je recommande ce Cours et tutoriels pour apprendre UML : Cours complet pour apprendre UML 2.0, une série de tutoriels par Laurent Audibert
je parles pour l'informatique de Gestion
Pour moi, la modélisation des données c'est Merise. La modélisation des classes applicatives UML dépendant de l'analyse Merise.
Pourquoi:
Merise et UML sont pour moi complémentaires et pas conceurrents.
Si on dis UML pour tout, on considère que l'application vaut plus que les données. Depuis quand ?
La grande tendance c'est l'objet à tout va, la modélisation UML etc ... Arrêtons nous un instant. Que veut le client ? Il veux des données qui représentent quelquechose pour lui. Des données qu'il pourra intégrer dans un outil décisionnel, consolider etc ...
Aujourd'hui au regard du relatif échec des bases de données Objet, la plupart des bases me semblent encore aujourd'hui de type Relationnel. Et rien ne remplace Merise sur la conception d'un modèle relationnel de données.
Ensuite on peu parler UML. Quelles classes pour quels traitements, qui à la résponsabilité de quoi et à qui déléguer. Comment communiquer de façon efficace sur les processus métiers (Diagrammes de Séquences etc...).
Voilà comment je l'utilise. Ni plus ni moins et si on me laisse le choix je n'en utilise que les diagrammes pour communiquer sur le projet avec les développeurs pour définir les règles et leur rendre plus facile la compréhension des Design Patterns et la maintenabilité du Système.
Les cartes CRC ne sont pas mortes
Tu peux implanter sur BD relationnel avec une analyse UML ?
En effectuant, l'analyse uml rien ne t'oblige à implanter sur une base Objet...
Air startout
Je suis d'accord sur ce dernier point mais pour moi le meilleur outil de modélisation pour une base relationnelle est Merise sous AMC Designer. Les MCD et MPD sont des standards sur les projets.
Seuls les MCT (modèle conceptel des traitements) peuvent être avantageusement remplacés par une modélisation UML
J'utilise UML depuis plus de sept ans maintenant et pourtant je n'ai pas d'expérience de génération de code. Pourquoi ?
Parce que je m'en sers pour modéliser des relations fonctionnelles entre applications et entre applications et utilisateurs. En gros je me sers principalement :
- des diagrammes d'activité pour décrire les enchaînements de processus métier de niveau entreprise : acteurs et tâches
- des diagrammes de classe et de packages pour décrire les objets métier par application : une application = un package
- des diagrammes d'interaction pour décrire les échanges entre les objets métier automatisés : plutôt les diagrammes de collaboration, plus pratiques quand il y a beaucoup d'objets en jeu pour peu de messages entre couples d'objets
Le but est de faire le lien entre plusieurs populations :
- - les utilisateurs, acteurs des processus d'entreprise
- les responsables des données de chaque domaine applicatif (DBA)
- les responsables des interfaces inter-applications
L'objectif n'est pas ici de produire du code, mais d'aider à comprendre comment on va produire le code (ou l'acheter et l'intégrer), et à quoi ça sert de le faire. Et de faire collaborer plusieurs groupes de développeurs ou responsables de domaines applicatifs.
Ceci requiert que chaque population concernée retrouve l'écho de ses préoccupations. UML facilite cette approche, parce que c'est un langage à plusieurs plans, et je n'en connais pas d'autre qui ait cette vocation d'associer plusieurs vues entre elles.
>Un utilisateur peut comprendre sans difficulté un diagramme d'activité, et aider à le perfectionner, tout en comprenant en quoi les tâches impliquent des objets métier de chaque package.
>Un DBA peut réutiliser le schéma des objets métier d'un diagramme de classe et le transformer en MCD, MLD, MPD merisien/relationnel.
>Un développeur d'interface ou responsable d'EAI peut reprendre les diagrammes de collaboration et la description logique des messages pour en faire la base de ses négociations avec ses interlocuteurs d'autres domaines.
UML pour moi, c'est ça : préserver avec souplesse l'expression des besoins de chacun en les associant d'une manière formellement cohérente.
Après, on passe aux méthodes et outils de développement propres à chaque domaine, où tout le monde retrouve sa liberté de mouvement et de choix. Y compris, et surtout, dans des approches non objet.
Je trouve cette vision très intéressante et effectivement, je comprends l'intérêt que peut apporter UML à ce niveau.
Du point de vue client, notamment d'un pôle architecture et intégration il est tout à fait intéressant de se plonger dans une optique de système d'information organisé autour d'une modélisation UML et d'intégrer les prestataires dans leur démarche.
La charge en amont pour le client est phénoménale pour atteindre ce stade (formation UML des utilisateurs et administrateurs, mapper les concepts métiers etc ...)
Pour moi la grosse partie du travail doit être menée par le client qui est prêt à en payer le coût.
S'intégrer dans un projet pour un client dont l'UML est une des clefs de l'organisation ne posera pas de problèmes car l'intérêt de l'UML et réel et le coût associé à la mise en oeuvre documentaire est bien compris.
Par contre, si le client ne se pose pas de questions par rapport à l'UML et que l'on débarque avec une méthodologie UML, le coût n'est pas forcément bien compris et surtout la formation utilisateur consommera beaucoup de ressources et une mauvaise compréhension des schémas peut entraîner une inadaptation de la solution.
UML oui, mais pour ceux qui sont prêts et qui le demandent.
Malheureusement aujourd'hui je constate que chez de très gros clients, les problèmes politiques et de compréhension entre services rendent difficile la mise en place de l'UML.
Parfois les clients espèrent que via un projet utilisant UML il vont faire en sorte de mettre en place l'UML dans leur entreprise. Le beurre et l'argent du beurre. La modélisation UML des processus métier d'une entreprise doit être un projet en tant que tel. Si le projet informatique est un projet de refonte complet du système d'information, le coup est jouable mais les coûts doivent suivre.
Re: re
Je fais mes applis sans utiliser UML (j'ai terminé mes études en 96 et à l'époque la seule méthode d'analyse qu'on m'a apprise est une méthode orientée BDDR et il s'agit de Merise).Envoyé par silvermoon
Notre prof nous avait montré les 3 pavés qui constituent la méthode dans son entier et nous a dit que pour l'utiliser complètement il faudrait se plonger pendant 3 ans dedans....
En pratique, de Merise je n'utilise que le MCD.
Pour le reste, je fais ça de tête à et à l'instinct.
Maintenant, si j'avais à développer une appli de 6 millions de lignes de code en C++ avec une centaine de milliers de classes différentes, je pense que je me pencherais sur l'utilité d'une méthode d'analyse orientée "production de code".
Une vie de dev sans formalisme
Je pratique la programmation objet depuis 88 en commençant avec ADA, programmation par objet pour les puristes.
À cette époque, la PME dans laquelle je travaillais, collaborait avec des sociétés de services bien connues, nos rencontres avec les développeurs étaient assez édifiantes, ils nous montraient les gros classeurs de conception formelle, à l'époque ce devait être Merise, et il semblait qu'ils ne les utilisaient pas réellement car entre temps tellement de choses avaient changé que cela était devenu inutile, et les délais ne permettaient plus de les actualiser.
Une expérience plus récente m'a pas mal éclairé aussi. Reprenant la direction d'un projet de 5 ans dans une toute petite entreprise, j'étais très surpris de la quantité de documents écrits par les équipes au démarrage. Au départ très content, j'ai vite déchanté lorsque je me suis aperçu que le décalage avec le code réel était en fait énorme, normal au départ, l'argent d'un capital-risqueur coulait à flot
Une expérience encore plus récente. La startup dans laquelle je débutais avait fait appel à une entreprise de service pour amorcer la partie en Java du projet. Ils ont commencé par faire de l’UML, des graphes de séquence, qu’en est-il resté ? Rien, nous étions dans une approche trop informelle avec des itérations trop nombreuses, essais, échec, tout effacé, recommencer… Ce type de formalisme n’a sans doute pas tenu le coup face aux contraintes de la vie réelle et la personnalité du CTO ?
En 16 ans, je n'ai jamais utilisé de manière formelle d'outils de conception et de formalisation, hormis la lecture de Grady Booch sur Ada et les Packages fin des années 80.
Je dois ma formation objet essentiellement à la pratique de NeXTStep/OpenStep/Interviews et donc l'apprentissage des Design Pattern par osmose... Comme me Jourdain je faisais....
La lecture du code des autres, de quelques bouquins, est la voie la plus utilisée non ?
Nous avons tenté plus d'une fois de faire acquérir des outils spécialisés, mais beaucoup trop cher pour l'employeur, nous utilisions en général les outils GNU, pas très chers il est vrai
Cela nous a t-il empêché de produire des applis de qualité? Non assurément, et les négociations avec les clients se situaient sur un autre niveau, et quelques slides suffisaient amplement.
De mon côté, plutôt académique, j'ai toujours noirci mes cahiers de mes schémas et réflexions, beaucoup de commentaires dans le code afin de retrouver mes petits, mais c'est vrai, c'est surtout bon pour soi même. Pour les autres il est essentiel d'avoir un document 'Concept', mais a t-on le temps? en général non, et ça n'intéresse personne à par soi même pour y voir plus clair...
Il y a une vraie culture de la bidouille, du hack, du patch, malheureusement...
Me trouvant au chômage actuellement, je m'aperçois que les annonces sont remplies d'UML, de Rationale et consort, alors je m'y mets pour avoir le vocabulaire et les bases afin de ne pas paraître ridicule.
Et il est vrai que la perspective de me mettre à mon compte fait que je l'envisage sérieusement. Il m'apparaît clairement que c'est un outil de communication indispensable. Mais ma vocation pour la simplicité me fait croire aussi qu'il est bon de l'utiliser pour les schémas généraux afin qu'ils puissent être réellement compris par le client, et par soi-même par la même occasion. Le code n'en sera que plus simple, et ce n'est pas un mal, vu la tendance à la complexité de certains codeur pur et dur, plus c'est tordu mieux c'est
Certains schémas font très peur quand même
Les méthodos c'est comme la prose: tout le monde en fait sans le savoir
Le besoin de méthodo n'a rien à voir avec tel ou tel langage: quel que soit le langage une méthodo est nécessaire parce que cette nécessité découle des contraintes d'environnement qui évoluent sans cesse, de la taille et de l'organisation des projets: travailler seul est beaucoup plus productif alors que dans une équipe de 10 personnes sa productivité décroît drastiquement sans méthodologie pour communiquer ou coopérer avec les autres.
Mais l'implémentation d'une méthodo dans tel ou tel langage présente plus ou moins de difficultés donc il est nécessaire d'y travailler par avance avant de s'y lancer tête baissée.
2 exemples concernant l'uml pour un projet
via dflp
http://www.nevrax.org/docs/
le premier http://www.nevrax.org/docs/img/nelnet_uml.png
le 2nd http://www.nevrax.org/docs/img/nelnet_uml2.png
UML
J'avais le bon présentiment qu' UML ne fait pas l'unanimité en France. MERISE y a le dessus peut-être pour sa simplicité et il y a aussi le fait que c'est "made in France".
Pour la plupart de mes projets je privilégie MERISE qui est suffisant pour des sujets "bateau" comme la gestion documentaire et compagnie... Des outils comme Visio ou Word peuvent faire l'affaire.
Pour UML, il devient intéressant dans certains cas vu qu'il a une syntaxe plus élaborée et que de nombreuses choses peuvent être modélisée de façon plus fine. Je l'ai utilisé pour la conception d'un système de contrôle d'accès à un site et dans un projet de modélisation d'un logiciel de taxation.
Cependant j'estime qu'un logiciel de modélisation (comme Objecteering) est utile pour gérer facilement la documentation et les nombreux modèles.
Par contre
Avec beaucoup de retard, j'ai regardé les exemples d'emplois d'UML d'aprés le lien fourni par Ovh. Ca me parait etre en fait une demarche inversée. D'aprés les contenus UML, il semblerait que les schemas aient été générés APRES que l'application ai été modélisée et developpée. Je pense que cet génération a été faite avec ModelMaker.
Le temps a passé et j'etudie maintenant au CNAM pour un DEST. L'UML est au programme dans le cadre de l'UV de programmation objet. C'est paradoxal, mais pas comme outil (de représentation) dans l'UV 'methodologie des systèmes d'information' dans lequel nous voyons SADT, Merise et OMT. Il aurait été interressant, par exemple, de voir un même projet, etudié via les 3 méthodes puis au final représenté par UML.
En revanche, parmis mes connaissances du monde du travail, rien n'a evolué concernant l'usage d'UML depuis mon post initial dans ce thread.
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.
UML : escroquerie intellectuelle ?
Tout à fait d'accord. Enfin quelqu'un qui brise le tabou. Le problème fondamental d'UML est qu'il n'est pas précisé exactement de quoi il s'agit : tantôt simple norme graphique, tantôt cadre de modélisation, voire même outil de conception, ce qui est une chose tout à fait différente. Si on le conçoit comme simple norme graphique, on peut effectivement l'utiliser; le problème est qu'on essaye à partir d'UML d'orienter la modélisation, ce qui est une aberration car UML est totalement déficient de ce point de vu. Un problème fondamental est l'absence de modélisation fonctionnelle globale du projet, qui doit être le préalable. Baser la réflexion sur le projet à partir des cas d'utilisation (les fameux use case) est totalement idiot, car c'est le projet lui-même qui va définir le mode d'utilisation, et pas l'inverse ! Il faut bien distinguer ce qui est interface de ce qui est fonctionnalité, la première dépendant de la seconde. Un autre problème d'une modélisation UML est la confusion entre modèle de donnée, fonctionnalité du projet et organigramme : si on prétend montrer les interactions fines entre classes, on va rapidement se trouver face à une usine à gaz ingérable.
Si vous ne trouvez pas d'exemple de modélisation intégralement UML appliquée à un cas réel et qui aille au-delà du retrait au guichet bancaire, c'est peut-être parce qu'il n'y en a pas !
UML est enfin le reflet des insuffisances du modèle objet lui-même, qui s'applique en réalité trés mal à la plupart des projets informatiques. Le modèle objet suppose de nombreux exemplaires (instances) d'un même type d'entités possédant leurs propres données et méthodes; or dans les projets on agit généralement séquentiellement sur une même donnée que l'on va modifier en fonction des besoins, ce qui fait qu'on n'utilise presque toujours une seule instance de chaque classe (à l'exception d'objets techniques comme des tables). La "programmation objet" se réduit souvent à utiliser des objets comme on utilisait les modules et les sous-programmes dans les langages traditionnels. Il y a malheureusement une "dictature de la mode" en informatique, où tout le monde fait semblant de trouver trés bien quelque chose de peur de paraître passéiste. Moultes vessies se croient lanternes....
Re: re
Salut , j'aimerais apporter ma pierre à l'édifice ...
Comme plusieurs l'on dit je pense que l'uml est une mode, tout comme le java, c est beau, sa plait aux clients sa montre que l'on est à la dernière mode. Mais franchement est ce que le code générer par les logiciels UML sont propre, j'en ai vu c est un peu le bordel.
Je lis pas mal de journaux sur l'évolution de l'uml et beaucoup disent qu'il y a encore du boulot de se coté là. Donc peut etre que l'on vite pour l'analyse mais si on doit reprendre le code derrière pas grand interet pour le moment mais je ne dis pas que dans l'avenir l'uml ne sera pas incontournable comme merise.
un pti aparté ceux qui ont touché aux bases de données et fait des shémas par exemple dans access ou autre et qui pensaient ne pas avoir utiliser Merise ils se trompent ils viennent de l'utiliser sans le savoir
J'ai lu la première page du topic et çà me suffit pour donner déjà un petit avis , et la dessus je rejoins silvermoon, UML pour moi est une mode ...
Cela fait 15 ans environ que je suis programmeur puis développeur et depuis quelques mois au chomage. J'ai obtenu mon BTS en 87 avec une approche très succinte de Merise. Pendant quelques années j'ai écris des programmes en basic (et oui) pour finalement changer de boite et programmer en RPG. Au bout de quelques mois de présence dans cette entreprise, changement radical de stratégie de développement. Grace à un chef de projet qui savait vendre ce qu'il faisait notre service info investit dans un AGL (Synon qui est devenu Cool 2E). Et ma foi , celà a changé radicalement notre façon de travailler. Toute l'équipe du service s'est mis à merise (mais avec une approche pratique plus que théorique) car l'utilisation de l'AGL nous y a obligé. Et nous sommes devenu beaucoup plus performant.
La plateforme que l'on utilisait était l'AS400 d'IBM. Et franchement, en dehors des écrans austère liés à l'environnement non windows(mais je sais qu'une version pour plateforme PC existe), je n'ai jamais trouvé un outil avec une approche aussi simple et aussi performant sur PC. J'avais que quelques mois d'expériences en RPG et s'il est vrai qu'il faut parfois plonger dans le code généré par l'AGL , mon peu d'expérience sur ce langage ne m'as pas pénalisé.
Peut on se permettre d'etre moyen dans un langage et utiliser un RAD ou AGL pour pc ?
En fait je n'ai pas vraiment trouvé d'outil aussi performant (je parle d'efficacité dans le développement) dans le monde PC et plus particulièrement objet, que celui que j'utilisais sur plateforme AS400.
Bref, je suis près à me mettre à la modélisation objet mais encore faut il etre convaincu du réel gain en efficacité qu'il peut nous apporter dans notre travail. Quand on a gouté à un AGL réellement efficace , il est difficile de revenir en arrière.
Voilà à+
Apparemment, les développeurs qui ont l'habitude de bosser avec leurs méthodes sont assez réfractaires à passer à uml, car ils ont l'impression de devoir casser leurs habitudes.
A mon avis, on parle beaucoup trop de uml et pas assez de méthode.
Je crois qu'avant d'unifier la modelisation, on devrait essayer d'unifier les méthodes de développement.
En effet, je préfère de loin une bonne méthode de développement "maison" avec des graphiques fait tantôt avec Dia, Paint ou Open-office qui finalement permet d'aboutir à mon résultat, en partant bien du problème, et en se remettant en question à chaque étape, puis en fournissant une documentation claire.
Parce que actuellement, j'ai l'impression que (à part pour les très grosses structures) c'est plutot, je réfléchit au projet, je te génère un diagramme de classe UML2 après avoir trouvé la solution, alors c'est sur que UML en lui même n'apporte pas grand chose.
Pour résumer, je dirai qu'avec les intervenants de ce topic, on pourrait en faire un autre qui pourrait être beaucoup plus intéressant, à savoir, que chacun explique en détail sa façon de travailler en fonction du type de projet, que se soit des méthodes reconnues ou personnelles.
Le jour ou tous les projets auront des méthodes en commun, et ou tous les projets de même type en auront encore plus, l'intéret d'UML (ou de l'un de ses successeurs) ne sera plus à démontrer.
Le bon millieu!!
La pertinance d'un choix de méthode de modélisation est plus souvent piloté par la taille de l'application ou du système à réaliser et par les contrainte de temps impartie pour la réalisation.
Mon avis est que peu de developpeur modélise à la mode UML ou Merise si le cahier des charges n'est pas bien lourd.
Il ne faut pourtant pas ecarter ces outils pour autant, ils peuvent étre une bonne source de réflexion sur ces propres méthodes d'analyse et constitue un pot commun identifiable (ou analysable) par la communauté des developpeurs. Ils peuvent étre un bon support pour les développement en equipe.
Personnelement, je ne les utilises pas mais m'en inspire pour la réalisation des documents techniques avec une adaptation plus "accéssible" au commun des programmeur!!!
UML->RUP
Bonjour moi ausi il y a des années je develloppais dans le noir ...puis vint Linux ; KDE et Umbrello depuis j ' utilise UML a tous les etage , c est une technique interresante ( on peux aussi bien faire de l ' architecture systeme que du composant ) mais UML prend toute sa puissance avec RUP.
Je ne vois pas pourquoi UML n'aurait pas sa place dans les petits projets. En fait, je parle d'UML, mais je pense principalement au diagramme de classe. C'est une méthode qui permet d'organiser son code (on parle évidement de programmation OBJET) et de voir comment il va fonctionner.
Le diagramme des classes est vraiment utile dans n'importe quel projet, les autres diagrammes sont là pour completer ....
tient, faite un petit tour dans le monde de l'Extreme programming. IL y a pas mal de bonne idée surtout celle qui dit de ne pas passer 3 mois sur une analyse en UML
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager